This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-08-11
Channels
- # admin-announcements (36)
- # beginners (1)
- # boot (267)
- # cider (19)
- # cljs-dev (12)
- # clojure (149)
- # clojure-austin (4)
- # clojure-canada (1)
- # clojure-czech (3)
- # clojure-dev (31)
- # clojure-japan (2)
- # clojure-uk (22)
- # clojurebridge (3)
- # clojurescript (314)
- # clojutre (18)
- # core-async (8)
- # cursive (4)
- # datascript (1)
- # datomic (27)
- # editors (2)
- # events (80)
- # hoplon (13)
- # javascript (2)
- # jobs (5)
- # ldnclj (12)
- # ldnproclodo (1)
- # off-topic (4)
- # re-frame (21)
- # reagent (87)
- # testing (13)
i can't see why not but i haven't tried it myself
how about supporting a URL scheme for bringing up a repl with a certain env
i suppose sharing a URL to a boot script is basically the same
@juhoteperi: any reason the docs for cljs.edn have been removed from the readme?
there was a reason but it was pretty much reverted
@martinklepsch: Docs restored
Thanks!
https://github.com/adzerk-oss/boot-cljs#same-html-for-development-and-production — this is the cljs default now right?
@juhoteperi: should we use your boot-less package to replace the hoplon5 *.inc.css combination functionality?
@martinklepsch: That’s why it doesn’t mention it would be special for boot-cljs
@juhoteperi: ah ok. Thought it might be a leftover from when CLJS didn’t handle this
@onetom: Sure you could use that
@juhoteperi: but is it the recommended way? Is there a sass/scss compiler too which is integrated w boot? I know about boot-garden but that seemed something totally different from CSS to me
@onetom: Recommended by who? I can recommend it, sure. Does that matter anything? I don’t know. 😄
@juhoteperi: by the clojure community. since u implemented such a thing u probably know similar tools, which makes you an expert on the topic transitively 😉
It depends on your needs and what you want to use. If you want to use LESS, it’s the best option. If you want to just use CSS and concat files then no.
Because I just use my own tool I haven’t looked into other options too much
I think e.g. boot-sass can’t load imports from classpath.
@juhoteperi: boot-less (and lein-less) are imo reason alone to choose less -- they are perfect
re-posted from IRC: what might be causing cljs.test/run-tests to return stale results when used with boot-cljs?
@pandeiro: In repl or file?
@juhoteperi: in the browser, so: file
my guess is maybe the ns that is calling cljs.test/run-tests is not getting re-compiled...
Is it being reloaded?
you can use :compiler-options {:verbose true}
to check what ns are being compiled
shouldn’t matter
the namespace which does run-tests requires the test namespaces?
in the case of my app, that ns' src is being generated dynamically from a boot task that takes ns args for which to test
:recompile-dependants
should then take care of recompiling run-tests ns
Yeah and it defaults to true
@juhoteperi: verbose output shows both run-tests ns and tests ns being re-compiled
...and subsequent compiles are staying fresh, even without touching the run-tests ns again
@pandeiro: maybe it's like with clj test, where the test ns adds meta to other namespaces or something?
I’ll check it later
@juhoteperi: appreciate it
@juhoteperi: is it cool if i push 1.7.48-SNAPSHOT to clojars?
What would be the best way to write a boot task that builds my clojurescript test cases AND runs them?
i.e. it will need to call node or whatever engine I'm using
@aengelberg: have you seen @crisptrutski’s boot-cljs-test?
Thanks, I'll try that
@aengelberg: if you encounter any issues, please file them or ping chris or me here.
@martinklepsch: the README has the artifact name wrong just fyi
i'm doing something similar with a project, wrapping the test prep and the test execution... i'll have to try this lib to see if it irons out some of the kinks i've hit
Using the "node" env doesn't work for me when only using the run-cljs-tests task, because doo is complaining about env attributes it can't see
@aengelberg: are you setting the js-env
option? https://github.com/crisptrutski/boot-cljs-test/blob/master/src/crisptrutski/boot_cljs_test.clj#L78-L79
@martinklepsch: @crisptrutski - should the 'simple way' of using boot-cljs-test work in combination with other compilations now that boot-cljs supports multiple cljs tasks?
yes, that’s on the roadmap
yeah, i was waiting on that release
will be in 0.1.0, should be out soon
hmm, or perhaps i should cut before changing this?
very similar to the tasks you and myguidingstar wrote
@crisptrutski: you haven't used this for CI tests by any chance, have you?
basically combined your tricks + bensu’s doo
don’t think so, at least not running any cljs projects through ci at the moment
just the return code to worry about right?
@crisptrutski: yeah basically... i've hit something really weird when running code like this on circleci
well, worth adding an example project with a circle config to this repo i guess
hands welcome
the even weirder part of my particular case is that i only hit this when using both boot-test and cljs-test
oh, i think i’ve seen that too
i wrote it off to having another boot-cljs task in the chain
but didn’t check
@crisptrutski: did it look anything like this - http://sprunge.us/HCVj ?
We will still need two cljs compilers for dev + test simultaneously right?
martinklepsch: you should be able to have multiple cljs.edn files with different compiler options in them...in theory
@micha: right. probably the test task should clone one, modify it and then build the cloned as well
but that still requires a separate build. We could not test the very same build that we made for development
(which maybe is also not something we want)
@pandeiro: no, just boot hung after running all suites correctly
also i’m guessing the exit codes don’t “compose"
@martinklepsch: doo needs to be in the build with its current design, so separate to dev makes sense to me
@micha: I’ve added a more minimal repro to that StreamClosed issue: https://github.com/boot-clj/boot/issues/270#issuecomment-129807599
also potentially we don’t want things like reload or repl in the tested build right?
@micha: re: the different .cljs.edn files - there was some reason for boot-cljs to switch from that to individual (cljs ...) task invocations, right? do you remember, specifically?
@pandeiro: It was reverted
@martinklepsch: ideally you'd want to be able leave out reload and any other namespaces you don't want to load
@juhoteperi: the 'one task, many *.cljs.edn' model is still how it is gonna work then?
@pandeiro: Reason was to have isolated environments (output dir and pod) for each build, but alternative implementation was chosen
don’t see the point in compiling code not directly under test into tested js in general
@crisptrutski: @pandeiro the test task could probably have some :filter-require
& :filter-init-fns
option with sane defaults
@pandeiro: I'll still as some kind of filter parameter for boot-cljs before next release
no i think you just create the test ns you want, with just the requires you want, and you give that as the param to (test-cljs :namespaces #{...})
so we’re generating the test ns for this plugin, so that the doo wrapping is involved
@juhoteperi: I’m confused now. 😂 What change exactly was reverted?
could look at a less invasive mechanism for doo, or modifying the runner ns though
@martinklepsch: One cljs task per .cljs.edn
that’s no longer the case?
@martinklepsch: It's back to one cljs task taking care of all .cljs.edn files
why can id
not be a set?
so how can I set different optimizations per build?
@pandeiro: it’s actually useful right here to do focused builds
@pandeiro: id = thing before .cljs.edn
@crisptrutski: Boot-cljs? No, not currently, but it will be, I think
Id is currently used to select only one .cljs.edn file
@juhoteperi: what is behaviour for id that isn’t found? generate a default edn?
@pandeiro: id is the name of .cljs.edn file
foo.cljs.edn -> :id foo
to avoid this https://github.com/crisptrutski/boot-cljs-test/blob/master/src/crisptrutski/boot_cljs_test.clj#L118-L119
@micha: Yes, it's only possible to select one
and that’s intended to stay, yes?
i agree w/ @crisptrutski that a #{} also makes sense
I found it quite handy when needing to make multiple builds with different optimization settings
@martinklepsch: that stuff goes in :compiler-options of the .cljs.edn file? e.g. :optimizations :none ?
@martinklepsch @pandeiro back to talking about custom runner namespaces, or filtering on namespaces
so is the problem that you want to do 2 things: * live version for development, and * test version to run cljs tests on
@pandeiro: then I can’t change it easily as part of different builds (prod vs. dev)
i was thinking just filtering on test namespaces as entry points
@martinklepsch: dev and prod were always just solved by different deftasks for me...
Could work: https://github.com/adzerk-oss/boot-cljs/commit/a946a6d9fa82320086d63cad1830dac9d173378f
should #137 not also be #{str}?
looks great
Fixed
If some one can think better name for the option, I'll listen 😄
@juhoteperi: i thought too id vs ids -- would :ids still be able to take a single string?
pandeiro: Just wrap the string in set
the functional interface is just a function
Yes, boot already takes care of that
boot-reload snapshot probably has :id option already. It's quite useful to be able filter out e.g. node build there.
that is great, so with that you can still just (cljs ...) compile everything without specifying :ids
No reason to limit it only that case, I'm thinking all cljs tooling should use same option
Well, infact it already does just that
@martinklepsch was clairvoyant and saw what boot-cljs would do before we implemented it
@martinklepsch: look into the future and tell me when @juhoteperi will cut boot-cljs 1.7.48 would you?
I'm thinking it'll happen soon
@pandeiro: It's availbe as :ids option now
right, i was just wondering then what else you wanted to include before 1.7.48 then?
I originally wanted to fix output dependency graph stuff but as dnolen is taking 2 week off proper fix will take some time
(:filter would be on the boot-cljs side, to remove stuff by regex or something -- not something i'm asking for btw, the boot-reload thing solves the problem)
@juhoteperi: any link to that?
I don't think so. It only affects boot-reload.
And it should work perfectly for cljs namespaces, current implementation just is a bit limited with foreign-deps. And it's implemented in boot-cljs and we should instead use cljs api.
@juhoteperi: right, cool. and dnolen is up for it? or you would try to submit a patch to cljs?
i'm wondering if i should already create an issue or wait til someone else reproduces this https://github.com/pandeiro/cljs-test-issue ?
@pandeiro: Yes, he agrees it's good feature but wanted an proposal about implementation before patch
@juhoteperi: cool, i agree it'd be great to have that dependably (for those cases when you want to debug js libs)
@pandeiro: quick start version works for me, 2 tests ran after the change
Ah right, it's supposed to work but doesn't work with boot
@juhoteperi: did the boot one work for you?
it is very non-deterministic; it will start to work after certain combinations of file touches, changes, etc
@pandeiro: Nope.
Clearly a bug with boot-cljs
but if you follow the directions exactly as written, for me it never works that first time
@juhoteperi: alright i'll issue it then? and start trying to dig in
hey has anyone ever had a problem with protocols not being loaded in the repl after it’s first started?
in my component systems, sometimes components error that another component doesn’t satisfy a protocol, which is clearly does.
going to the component file that implements said protocols and saving it solves the issue
@pandeiro: Something to do with our shim namespace, using :init-fns in cljs.edn can be used as workaround
@juhoteperi: did you push a new snapshot?
pushed now
Now I really have to eat 😄
@juhoteperi: enjoy!
@pleasetrythisathome: extending protocols to records/components in different files often leads to that problem. when you reload, you reload only the file where the record was defined and not where it was extended. then, the refreshed record doesn't know about the extend part until you go there and reload it
@bensu that makes sense. in my case i’m defining protocols in one file. and then defining records that implement protocols in their definitions in another file. does the same problem apply? seems like if the record file is reloaded it should know what protocols it implements
@pleasetrythisathome: I'm not sure. I don't know how redefining a protocol works, but I'll guess that in the end it is the same problem. the record that remains loaded is pointing to the old definition of the protocol, which might not be the same thing as the new one
my only solution to this is to use the reloaded workflow and reload every namespaces in those cases
i do use the reloaded workflow 😞
it looks to me that all the relevant namespaces are being reloaded
i’ve been thinking its a dependency graph problem
that the protocols are somehow loaded after the record files
I don't have much insights... one last thing is that if you have introduced a circular dependency during refactoring, you won't notice in the REPL and might get strange effects like this one. if you haven't done it already, try running the code from clean state.
yea circular dependency is a good thing to check
@martinklepsch: @juhoteperi @pandeiro boot-cljs-test is out with latest boot-cljs
0.2.0-snapshot
feedback and testing really welcome
@juhoteperi: When modifying :asset-path
in a .cljs.edn
file should I expect this to be picked up in a watch cycle?
@martinklepsch: Chaging compiler options probably doesn't work too well without restarting the process
we could easily detect this with fileset-diff and rerun make-compiler
when cljs.edn files change
I think it worked before actually — could that be?
@juhoteperi: having trouble passing :main option to new boot-cljs task
@crisptrutski: use :require option in .cljs.edn
@juhoteperi: reason not supporting it via :compiler-options anymore?
my use case is actually wanting the default-main edn, but with a specified main
Probably partially unintended consequence of changing shim ns logic
i’m trying to avoid duplicating default-main in my own code to work around this
If you set :main option manually :require and :init-fns are completely ignored
though if you don't use cljs.edn that doesn't matter
perhaps warning if file exists and option is set?
Not that simple as the cljs.edn exists always when shim ns is being generated, as it's created first if it doesn't exist
i think this is actually a clobbering issue
the merge in wrap/compiler-options
main
has {:compiler-options {:main nil}}
in my case
https://github.com/adzerk-oss/boot-cljs/blob/master/src/adzerk/boot_cljs/middleware.clj#L70
We could probably allow setting any options manually with warning if they are set
like that output-to was removed - was actually using that but it’s quite abusive
warning for that would be useful for migration though
context’s {:opts {:main ns}, :main {:compiler-options {:main ..}}}
shape is quite confusing
crashes my mainframe 😖
(warn "You are manually overwriting Boot-cljs set option for %s, I hope you know what you are doing!" k)
yeah, i’m trying out something like that
feel that [:main :output-dir :output-to] are in distinctly increasing levels of abuse though