This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-01-08
Channels
- # aws (4)
- # beginners (81)
- # boot (65)
- # cljs-dev (10)
- # cljsjs (1)
- # cljsrn (12)
- # clojure (26)
- # clojure-austin (2)
- # clojure-dusseldorf (2)
- # clojure-russia (123)
- # clojure-spec (23)
- # clojure-uk (12)
- # clojurescript (36)
- # cursive (11)
- # datomic (39)
- # events (1)
- # hoplon (25)
- # incanter (4)
- # leiningen (3)
- # off-topic (5)
- # om (31)
- # re-frame (24)
- # reagent (13)
- # ring-swagger (2)
- # rum (10)
- # untangled (3)
- # yada (10)
how can I debug my build.boot file?
I can't even run boot help
-B
disables loading of build.boot
in current dir @vinnyataide
Then there is also -b
which prints the generated build script, but not sure if you need that, if you can provide a specific error that makes it easier to help you 🙂
-B is good thanks
it's exactly what I was looking for, there was a task call inside that was wrong, so disabling it I could eval each line
the error message is:
ClassNotFoundException reloaded.repl java.net.URLClassLoader.findClass (URLClassLoader.java:381)
@juhoteperi @richiardiandrea Hey 🙂 Do you have an opinion on removing the autogeneration of main.cljs.edn? I want to disable it somehow and while that can be implemented in a backwards compatible way I wonder if we shouldn’t just remove it all together and print a warning for people who relied on it
I am for removing it, but I guess many code bases rely on auto generating, @flyboarder was proposing a task, which could be enabled by default with the option of turning it off (therefore not generating)
Actually we could add an option for disabling that part, what would be the use case you have in mind?
I generate cljs-edn files in the task pipeline and sometimes there a no files to generate in which case the compiler still ends up compiling “main"
@martinklepsch, how about:
- cljs --edn
compiles all edn
- cljs --auto
auto-generated main.edn
- cljs
warns that calling the task without an explicit flag is deprecated but continues the current behavior ?
Yeah that sounds like an option
I was also thinking maybe we split the two tasks into cljs
with automatic edn and cljs*
without automatic edn
Then we add a deprecation warning
and at some point we just rename the cljs*
one back to cljs
@martinklepsch what about using the :ids
option to indicate this behavior?
you can use (cljs :ids #{"*"} ...
to indicate "compile all .cljs.edn files but only if there are some"
if you have (cljs :ids #{"foo" "bar"} ...
it already works the way you want it to, right?
Yes but I can’t explicitly pass all IDs because the cljs.edn files are generated as part of the pipeline
2. cljs.edn files are generated by user in pipeline and no ids are specified as cljs option
3. cljs.edn files are generated by user in pipeline and ids are specified as cljs option
so if you don't know the ids before hand, but you know that you don't want cljs to autogenerate main, you can do :ids #{"*"}
I'd like to see some descriptions of cases where multiple builds are used (multiple target envs?). I have never used it and to me all this seems just too complex.
even separate dev and test builds sounds kind of bad solution because the code base is mostly the same and separate builds don't share compiler state
so it will do lots of unncessary work
I’m toying with an idea where the separate compiler state is actually quite nice, will tell you about it later though, have to sleep now 😄
Okay.
One idea I've been toying about would be to drop support for multiple builds from Cljs task and instead somehow support parallel tasks and... "modifying pipeline dynamically" (or creating it dynamically)
interceptors! 😄
That would be a nice 3.0 feature 😄
Perhaps
There are some cases where middleware pattern isn't perfect fit, like task cleanup hook currently
i wonder how much interest there is in a boot 3.0.0 that has lower level access but is backwards compatible with 2.x?
but then you have to support both? 😛
i think we could do it in a clean way, for example separating the work (the handler) from the middleware
could be separate from the middleware, which complects control flow with the work being done
I think it would great to collect use cases somewhere: in my experience the problem with cljs.edns is more of state sharing and it happens only if no cljs.edn is there and I need the compiler options before boot-cljs
runs..I haven't had any other trouble with boot so far.
I would like to propose a pattern for the option (nothing new, the one that lambone
uses) so also maybe we can create a boot 3 wiki subsection
@juhoteperi I use multiple builds for different parts of the app (customer-facing and dashboard)
@pesterhazy That could also be done using Closure modules (though I'm not sure how easy that is currently)
Yeah I used to use multi builds in an old project exactly because I did not know about cljs modules