i can't see why not but i haven't tried it myself

Hello friends and uncles.

hey @devn!

what's upppppp @micha

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

i've checked that the test ns in question is getting recompiled...

my guess is maybe the ns that is calling cljs.test/run-tests is not getting re-compiled...

Is it being reloaded?

i am refreshing the browser

Okay

i think cljs.test/run-tests is a macro...

you can use :compiler-options {:verbose true} to check what ns are being compiled

shouldn’t matter

let me do that

i also have a minimal repro example

the namespace which does run-tests requires the test namespaces?

deraen: it does yes

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

but in my minimal repro, i am doing it statically

:recompile-dependants should then take care of recompiling run-tests ns

is that a compiler option?

Yeah and it defaults to true

ok

@juhoteperi: verbose output shows both run-tests ns and tests ns being re-compiled

but the results are the same: stale output from run-tests

interestingly, if i touch the run-tests ns, the test output is fresh again...

...and subsequent compiles are staying fresh, even without touching the run-tests ns again

@pandeiro: if you are running in a browser, might it be the browser caching?

(btw thanks for the Docker images )

@bensu: i'll check with a hard refresh

yep, still reproducing with hard refresh

hhmm

@pandeiro: maybe it's like with clj test, where the test ns adds meta to other namespaces or something?

so when you touch the test ns it applies new meta to the namespaces it's testing

@micha: in a couple secs I'll have the simple repro on github

I have a boot version and a cljs quick start version

with quick start i can't reproduce the issue so far

here it is: https://github.com/pandeiro/cljs-test-issue

there are instructions in the README for how to reproduce

I’ll check it later

@juhoteperi: appreciate it

@juhoteperi: is it cool if i push 1.7.48-SNAPSHOT to clojars?

@micha: yes

groovy

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?

https://github.com/crisptrutski/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

ouch

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

neat

will be in 0.1.0, should be out soon

hmm, or perhaps i should cut before changing this?

I'm reading through the source now, curious how you're doing it

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

awesome

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

where the boot process just hangs during or after cljs compilation

it happens only every 2 out of 3 times

once every three times, it works great!

ouch

heh

well, worth adding an example project with a circle config to this repo i guess

that's a good idea, i can help if you want

hands welcome

the even weirder part of my particular case is that i only hit this when using both boot-test and cljs-test

using either by itself, the tests run fine

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

each one gets its own pod and cljs compiler instance now

@micha: right. probably the test task should clone one, modify it and then build the cloned as well

sounds pretty sweet

but that still requires a separate build. We could not test the very same build that we made for development

i like the sound of that, tasks figuring things out and just doing them

(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

@pandeiro: Yes

@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

ah ok

why can id not be a set?

so how can I set different optimizations per build?

what was the need for id, specifically? the filename itself is not unique enough?

@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

ah so there's no new :id key in *.cljs.edn ?

@juhoteperi: what is behaviour for id that isn’t found? generate a default edn?

@pandeiro: no

ah to filter them, ok

@pandeiro: id is the name of .cljs.edn file

foo.cljs.edn -> :id foo

yeah i see

to avoid this https://github.com/crisptrutski/boot-cljs-test/blob/master/src/crisptrutski/boot_cljs_test.clj#L118-L119

ids still work, right?

and if you don't include :id, then it builds all of them

@micha: Yes, it's only possible to select one

ok cool

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

is that correct?

@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...

@micha: yeah dev and test1 ... testn builds

i'd like to be able to run those on a watch and run them adhoc from the repl

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

yeah sure, and maybe display that in error if person tries

(or maybe boot already shows that if the arg type doesn't match)

Yes, boot already takes care of that

and then to get boot-reload out, there would need to be a special :filter param?

or could boot-reload itself not specify a build id?

boot-reload snapshot probably has :id option already. It's quite useful to be able filter out e.g. node build there.

you probably only want boot-reload on one build usually i imagine

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

yeah sure, i agree

so boot-reload should also maybe take :ids #{} ?

Yeah

starts to feel like a uniform interface

Well, infact it already does just that

perfect

@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?

haha

I'm thinking it'll happen soon

you still want to add the :filter thing?

@pandeiro: It's availbe as :ids option now

in boot-reload you mean?

@pandeiro: Yes

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?

@pandeiro: http://dev.clojure.org/jira/browse/CLJS-1407

could that be related to my cljs.test issue at all?

I don't think so. It only affects boot-reload.

yeah no doesn't seem like it

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?

@martinklepsch: Nope

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

that would create a new pod etc

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

Try this: https://github.com/adzerk-oss/boot-cljs/tree/allow-manual-opts

feel that [:main :output-dir :output-to] are in distinctly increasing levels of abuse though