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)
@juhoteperi: any reason the docs for cljs.edn have been removed from the readme?
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?
@juhoteperi: ah ok. Thought it might be a leftover from when CLJS didn’t handle this
@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.
@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?
my guess is maybe the ns that is calling cljs.test/run-tests is not getting re-compiled...
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
...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?
What would be the best way to write a boot task that builds my clojurescript test cases AND runs them?
@aengelberg: if you encounter any issues, please file them or ping chris or me here.
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?
@crisptrutski: yeah basically... i've hit something really weird when running code like this on circleci
the even weirder part of my particular case is that i only hit this when using both boot-test and cljs-test
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
@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?
@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
could look at a less invasive mechanism for doo, or modifying the runner ns though
to avoid this https://github.com/crisptrutski/boot-cljs-test/blob/master/src/crisptrutski/boot_cljs_test.clj#L118-L119
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)
@martinklepsch: dev and prod were always just solved by different deftasks for me...
Could work: https://github.com/adzerk-oss/boot-cljs/commit/a946a6d9fa82320086d63cad1830dac9d173378f
@juhoteperi: i thought too id vs ids -- would :ids still be able to take a single string?
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
@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?
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)
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)
it is very non-deterministic; it will start to work after certain combinations of file touches, changes, etc
but if you follow the directions exactly as written, for me it never works that first time
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
@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 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.
@martinklepsch: @juhoteperi @pandeiro boot-cljs-test is out with latest boot-cljs
@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
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
https://github.com/adzerk-oss/boot-cljs/blob/master/src/adzerk/boot_cljs/middleware.clj#L70
like that output-to was removed - was actually using that but it’s quite abusive
context’s {:opts {:main ns}, :main {:compiler-options {:main ..}}}
shape is quite confusing
(warn "You are manually overwriting Boot-cljs set option for %s, I hope you know what you are doing!" k)
feel that [:main :output-dir :output-to] are in distinctly increasing levels of abuse though