This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-07-11
Channels
- # aws (15)
- # beginners (55)
- # boot (116)
- # bristol-clojurians (2)
- # cider (4)
- # cljs-dev (439)
- # cljsrn (14)
- # clojure (135)
- # clojure-argentina (3)
- # clojure-czech (4)
- # clojure-italy (60)
- # clojure-russia (1)
- # clojure-spec (48)
- # clojure-uk (42)
- # clojurescript (170)
- # cloverage (11)
- # core-async (19)
- # cursive (13)
- # datomic (48)
- # emacs (2)
- # graphql (3)
- # hoplon (8)
- # jobs (1)
- # jobs-discuss (5)
- # klipse (11)
- # luminus (5)
- # lumo (5)
- # mount (48)
- # off-topic (96)
- # om (17)
- # onyx (14)
- # parinfer (30)
- # protorepl (1)
- # re-frame (90)
- # reagent (2)
- # remote-jobs (1)
- # spacemacs (12)
- # specter (20)
- # uncomplicate (1)
- # untangled (65)
- # vim (2)
- # yada (8)
Hi, We're having a problem with boot-cljs
. Running the same task several times doesn't produce the same build. Specifically, sometimes it's build with :advanced
optimizations as specified, sometimes not. Similarly, it doesn't always take the :libs
option into account, resulting in missing JS code in the final build. To be clear, we tried to the :optimizations
options everywhere : in a .cljs.edn
file, in the :compiler-options
of the task option, and at the top-level of the task option itself. The only almost reliable way we found was to duplicate the options everywhere applicable (both :libs
and :optimizations
). Yes, this is silly, but this is the way it works the most often. The problem exists with the latest 2.0.0
version of boot-cljs
and the previous one.
Code (stripped out data, with some comments for you) :
clojure
;; build.boot
(def trackers-libs [ "trackers/google_analytics.js"]) ;; real list is longer
(def ref-src-trackers "trackers/src")
;; this one is used at several places, hence a raw call to `(cljs)` configured elsewhere with `(task-options!)`
(deftask task-assets
"Main task to build assets"
[c css-output-style VAL kw "Css output style"
s css-sourcemap bool "Css sourcemap"]
(comp
(sift :invert true :include #{ #"^(.+?)main.scss$"
#"^(.+?)mainfloat.scss$"
#"^(.+?)duplos.scss$"
})
(sass :source-map css-sourcemap :output-style css-output-style)
(cljs)
(sift :include #{ #"^(.+?).js$"
#"^(.+?).map$"
#"^(.+?)yoda.css$"
#"^img[/\\](.+?)$"
#"^fonts[/\\](.+?)$"})
(sift :move { #"^scss[/\\]yoda.css$" "css/main.css"
#"^scss[/\\]yoda.css.map$" "css/yoda.css.map"})))
(deftask build-assets
"build yoda assets"
[]
(set-env!
:source-paths #{"src/cljs" "src/cljc" ref-src-trackers}
:resource-paths #{"resources" "cantina/duplos/src"})
(task-options! cljs { :ids #{"js/main"}
:optimizations :advanced ;; DUPLICATE!
:source-map false ;; DUPLICATE!
:compiler-options { :optimizations :advanced ;; DUPLICATE!
:source-map false ;; DUPLICATE!
:libs trackers-libs}}) ;; var trackers-libs reused everywhere we need to build cljs
(comp
(task-assets :css-output-style :compressed :css-sourcemap true)
(sift :include #{ #"^js/main.out(.+?)$" } :invert true)
(target :dir #{"yoda-assets"})
(tar-assets)))
;; main.cljs.edn
{:require [yoda.core]
:init-fns [yoda.core/init]
:compiler-options {:optimizations :advanced ;; DUPLICATE!
:source-map false ;; DUPLICATE!
:libs ["trackers/google_analytics.js"] ;; DUPLICATE!
:parallel-build true}}
Note that we ended up in this crazy duplication state because things started not working in almost 100% cases. The bug happens on Linux, locally or in Jenkins (also runs under Linux).
Help, please 😢Maybe I should open an issue, I don't know. Even duplicating options everywhere doesn't help getting a consistent output.
@djebbz options to tasks are global when you use task-options!
(that is why there is an exclamation mark), so unfortunately once you set them, you can change them only by overriding (duplicating in your case)
We'll try using only task-options
then. I'll report back (after lunch 🍜). Thanks @richiardiandrea
You would probably need to drop it actually, depending on how many things you need to customize - or use task-options!
for options that are not dynamic and direct options otherwise
Don't use task-options
with cljs
at all
Especially from deftask
task-options
is like defn
, you don't want to create side-effects from tasks like that
@juhoteperi So you mean one should use task-options!
only for options that stay the same across all tasks ?
preferably set-env!
should also be used only at top-level, not inside tasks, but unfortunately there are some cases where it can be required
Yes, I definitely see in our boot file cases for task-level set-env!
(different classpaths for clj and cljs)
Does -v[vvv]
works at the pipeline level or at the task level ? Said another way, do I need to use only once at the beginning of the command-line or before each task invoked ?
@djebbz only once
MERGE TIME 😄
please consider https://github.com/boot-clj/boot/pull/551 @alandipert 🙂
I’ll push a changelog entry once it’s merged
:thumbsup:
things are looking good for the summer release!
really appreciate the work people have done vetting and tagging
(and untagging)
especially @martinklepsch 🙌
@alandipert I think @richiardiandrea deserves most of the praise 😛
✅ retain pillsbury theme
Haha yeah, key point. 😄
it sucks that changes.md is always a conflict
i wonder about compositing it at build time from a few different files to make things easier on git
or rather, a script to generate it from a few flat files or something
@alandipert ah yeah that’s annoying indeed. (reminds me of that migration system I’ve been working with where migrations where numbered w/ incrementing integers)
PRs could add files with their changelog entries to .changes, script could consolidate them into changes.md
@martinklepsch btw i’m done with the merging, feel free to add to changes.md now
awesome!
https://github.com/boot-clj/boot/pull/612 — this one might be worth consideration as well?
I'd release and merge this one for the next -alpha
⚡ new 2.7.2-SNAPSHOT
deployed, here’s what’s in it: https://github.com/boot-clj/boot/milestone/23?closed=1 ⚡
@alandipert there are a couple of docs PR, shall we merge them
@richiardiandrea sure, pls also add issues to next-release milestone
@alandipert I don't have issues for https://github.com/boot-clj/boot/pull/622 and https://github.com/boot-clj/boot/pull/621 but they are pretty small
I am rebasing 623
cool done
Adressed the remaining issues with #598: https://github.com/boot-clj/boot/pull/629
@martinklepsch Looks good, I just need to check what with-let
does...
Okay, it binds fs/skip-subtree
to _
, evaluated body, and returns _
I don't see why the macro is used here, but works
@richiardiandrea @juhoteperi reporting : I rewrote our tasks that used boot-cljs
so that they use only the :compiler-option
: no task-options!
, no x.cljs.edn
file, no top-level cljs options (`:optimizations` and :source-map
). It just works. Sad to say that what boot-cljs
adds isn't very reliable (yet?). It's almost like we're using the raw clojurescript compiler. Thank you guys for your assistance !
Well, I haven't had problems with Boot-cljs in long time, which is why it hasn't seen much development. And it is supposed to be only very light tooling over ClojureScript compiler.
@djebbz I think that a light wrapper on top of the compiler is the only thing you actually need, in case things go wrong, you don't want to debug layers on top of layers of indirections...`boot-cljs` does its job very well imho 😄
Hmm, though .cljs.edn
definitely works for me.
also very happy with .cljs.edn stuff usually 🙂
I think it's using cljs.edn files and task-options and inline options at the same time that caused us problems
There might be problems especially with merging some compiler-options.
But the task option merging order is documented: https://github.com/boot-clj/boot-cljs/blob/master/docs/compiler-options.md
well, in fact that says that task-options
are merged over .cljs.edn
My understanding is that it's either cljs.edn or not at all, but not mixing both and hoping that options will merge : looks like they don't
these issues are difficult to debug, it would be great to have some reproducible case and see which options don't work for you
Hmm, though that doesn't describe how task-options!
work, that is provided by Boot and not seen by Boot-cljs
"task options" are both the parameters to cljs
task and options to task-options! :cljs
Not sure how Boot merges those
I think I usually don't use task-options!
with Boot-cljs.
Hmm, I quite sure that Boot core can't merge :compiler-options
maps if you set one using task-options!
and another on cljs
params
Because Boot can't know how Boot-cljs options should be merged
But Boot-cljs doesn't see task-options!
, Boot merges those before calling Boot-cljs code
What you can do is process your .cljs.edn file in a boot task - this way you can get all the dynamic-ness you want while still keeping the nice aspects of having a .cljs.edn
I'll add issue to Boot-cljs about this, there might be some way to workaround this, or give warning.
Looks like task-options!
is implemented so that it saves the task options to task function metadata, so Boot-cljs could at least check if something is set there.
And if the original cljs
call parameters can be found some where, Boot-cljs can merge them correctly
I think that already has task-options!
merged into
My ~/.boot/cache
is huge. It's over 8GB, and that was after I stopped to check the size when`rm -rf` was taking over a couple of seconds. Is this expected? Is there a standard way of clearing it out?
One reason to clear it out is just to reclaim space: the other is that I had a file showing up (in clj-refactor IIRC) that was no longer in my source tree.
I'm not sure but I think boot cleans the old tmp-dirs of a project when starting a new Boot process
But the caches are per project, so if you have large project a
, the old tmp-dirs for that will stay around until you start Boot process on that project, and then it will create new dirs
@richiardiandrea I thought I had a solid repro for https://github.com/boot-clj/boot/pull/474 but can’t find it right now, will try to provide one this week
Starting boot process on my saapas
project, removed one tmp-dir and creates another
But there is a second directory that it didn't touch
Not sure why
@martinklepsch that would be awesome, however I spent some time on it without finding a solution and that is why I guess micha put "help wanted" 😄
yeah, could be I’m confusing it with something else as well
not 100% sure
When Boot initializes TmpRegistry for a project, the old directories with .delete-me
file are removed, when Boot successfully exists, that file is created: https://github.com/boot-clj/boot/blob/ac835cea8c18e926bb843e01579b86e3f30458d2/boot/core/src/boot/tmpregistry.clj#L79-L80
If Boot crashes, no .delete-me
file is created, so in that case the directory is not removed
I can understand that why you might want to keep a crashed tmp directory from a debugging perspective. Would it make sense to have some kind of ensure/finally that creates that file otherwise? I've definitely been crashing boot quite a bit as I've been learning.
Not sure if finally
or such would be enough, in some cases, even that can't be called
e.g. OS kills the process due to out of memory etc.
Instead we could write PID to the file and check if it is still running
Similar to what daemon processes usually do in unix
But I'm not sure how easy that would be to implemented so it works for Windows also, and if Java process can even check for running programs easily
Do you think it would make sense to have a boot task that would clear out the cache manually? Or is rm
the appropriate interface?
What do I have to do to get a proper uberjar? I did specify the task options, aot
the main ns, and set it as main ns for the jar, then did boot aot pom uber jar target
. But executing java -jar target/myproject.jar
only gives me a Error: Could not find or load main class
.
I'm working on a library that I'd like to have work with two different versions of one of its dependencies. So for one of the tasks I'd like to pull in this different version. Is this just a matter of munging the boot environment with set-env!
? I was eyeing the "Task environment conflicts" snippet and thinking that might be a good starting point. https://github.com/boot-clj/boot/wiki/Snippets#task-environment-conflicts
The alternative of commenting/uncommenting portions of build.boot doesn't really appeal 🙂
I have a project with separate client CLJS and server CLJ app repos. When I'm working on both the server and client, I'm running each in a separate Boot process. The output of the CLJS app dumps its compiled CLJS files into the server app's file tree, which then refreshes its file index. Currently Boot-Reload reloads the browser as soon as the CLJS files are done compiling, but that is before the the server Boot process has had a chance to reload its file index. I'm wondering if there's a trick to getting Boot-Reload to run AFTER the server Boot process refreshes its file index. Another option would be to have the server load from an external resources folder that is updated directly by the CLJS process.