This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-08-10
Channels
- # admin-announcements (1)
- # alda (1)
- # bangalore-clj (1)
- # beginners (94)
- # boot (139)
- # braveandtrue (1)
- # cider (19)
- # cljs-dev (21)
- # cljsjs (8)
- # cljsrn (79)
- # clojure (124)
- # clojure-austin (1)
- # clojure-belgium (1)
- # clojure-berlin (3)
- # clojure-hamburg (3)
- # clojure-quebec (1)
- # clojure-russia (77)
- # clojure-spec (5)
- # clojure-uk (18)
- # clojurescript (39)
- # conf-proposals (21)
- # core-async (5)
- # cursive (8)
- # datomic (40)
- # defnpodcast (1)
- # devcards (14)
- # dirac (5)
- # editors (1)
- # emacs (4)
- # jobs (1)
- # liberator (4)
- # onyx (29)
- # perun (15)
- # proton (15)
- # protorepl (9)
- # re-frame (47)
- # reagent (38)
- # ring (1)
- # rum (7)
- # specter (23)
- # untangled (8)
- # yada (55)
so I have a weird configuration a little, and I need to specify :compiler-options {:asset-path ...}
in the cljs.edn
files (I have three js files) and plus this path can change based on the if I am running dev or staging
so I would really like to ask if there is something like :asset-host
so that I don't have to specify the name of the .out
folder
or what are the alternatives (if any) to intercept and rewrite the cljs.edn files
based on the build type
how can I sift js files to specific path after cljs task? I've tried something like this:
(deftask dist []
(comp (cljs :optimizations :advanced)
(garden :styles-var 'cms.styles/screen :vendors ["webkit"] :auto-prefix #{:animation})
(sift :move {#"main.css$" "../src/main/webapp/statics/css/sns/cms_editor.css"
#"editor.js$" "../src/main/webapp/statics/js/sns/cms_editor.js"})))
@doglooksgood: sift only works within the fileset. not possible to move files outside of it (you can write a task that does http://java.io stuff)
the src/main/webapp/
directory, does that belong to the same project?
@martinklepsch: got it.
yeah, either move via http://clojure.java.io or use target
and a shell script 🙂
I got some problems fetching 2.6.0
, network is slow in China but I tried more than 10 times but still failed.
@jiyinyiyong: you could checkout the git repo and do git checkout 2.6.0
and then follow instructions from https://github.com/boot-clj/boot#hacking-boot
that will install 2.6.0 to your local ~/.m2
^^ alternate download of boot.jar, will still talk to clojars when you run
rename to boot
and chmod u+x boot
to make executable, then put on path
err, hold on, that's wrong
if you have the repo cloned i think your best bet is to build locally
that process does download stuff, but from maven central, not github
mvn == maven
brew install maven
should do it
I have the following setup that I wonder if boot could accomodate. As I understand it boot is generally not creating files which I like. But can I somehow pass the temporary file location to a node script and run the node script before terminating the boot task?
isolate the build steps that assume they can run wild on the filesystem to the temp dirs encapsulated by a task
your build pipeline consists of a number of steps, each contributing to the final artifacts
the input end of the pipeline is your project files, :source-paths, :resource-paths etc
when you use jvm tools in your build steps, like the java compiler for example, they all expect to find their inputs on the classpath
the downside of this normally is that they assume that they can write to the globally shared filesystem
boot tasks address this by carefully controlling what the java compiler sees as input, and controlling where it can write its output
it passes the paths to these files (files in the fileset also exist in temp directories on the filesystem, and are on the classpath)
so it passes the paths to java compiler and configures the compiler to emit class files into a temp directory created by the task itself
after the java compiler has compiled the java source into class files, and written those files to the temp dir, the task adds the contents of the temp dir to the fileset it was given
the task then calls boot.core/commit!
on the newly created fileset object, which syncs its state with the actual filesystem underlying the fileset
this gives the task the ability to strictly control how the output of the java compiler is incorporated into the pipeline
the pattern is sketched out here: https://github.com/boot-clj/boot/wiki/Tasks#task-anatomy
Totally! So the files generated are available ephemerally and passed on as long as the boot process runs? But how do I concretely launch a node process pointing to the generated files?
but there must be a way to configure it with input directories, which you can create yourself in temp dirs in your task
or if it insists on writing to the input directories (ouch!) you can even accomodate that
Basically it is as simple running a terminal command with the output directory/file as one of the arguments
yes, and boot has boot.util/dosh
for when you want the output of the process streamed to stdout in real time, rather than after the process terminates
(require '[boot.core :as b]
'[my.compiler :as c])
(b/deftask foop
[] ;; options here, it's a whole thing
(let [outd (b/tmp-dir!)]
(b/with-pre-wrap [fileset]
(let [inf (->> fileset
(b/input-files)
(map b/tmp-file))]
(c/doit :output outd :input inf)
(-> fileset
(b/add-resource outd)
(b/commit!))))))
if you need to reorganize the files from the fileset into a different tree in the input directories for the node thing, you can do that too
boot also has a bunch of efficient patching, diffing, and syncing functions you can use later to speed things up
if you're not familiar with the functions i used you can see them here https://github.com/boot-clj/boot/tree/master/doc
That makes a great starting point! Not understanding everything off the bat, but I’ll dig into it. Thanks a bunch! Very warm welcome to boot land, just migrated my React Native project today from leiningen.
it would be super interesting to see if it's possible to run node in nashorn or something
yeah in any case if you get something going that works we can help you optimize it later, there are a bunch of things boot provides to help with that
@vikeri: someone also just posted this brand new boot-npm task the other day, could be helpful? https://github.com/degree9/boot-npm
Hi! I'm having a weird issue with using a package from Clojars and wondering if it has something to do with Boot.
I made a library that have a dependency from external Maven repo. I added this repo to env (via (set-env! :repositories #(conj % '[...]))
) and everything works fine locally. When I pushed this lib to Clojars and added it to another project, I got a org.sonatype.aether.resolution.DependencyResolutionException
. I guess that Boot should've added this repository to .pom
-file, but I couldn't find any mentions of repositories in pom.
yeah, I thought that it should be a transitive dependency
(never heard of this term before :)).
my thinking is that the <repositories>
element in the pom is like :repositories
in the build.boot
yeah, but when you’re using this library from clojars, you have to add those repos manually in each project. anyway, I think that’s okay since I can just specify this in a library documentation.
that being said, it might be a good idea to add the <repositories>
to the pom, if only to ease debugging
seems like good practice from a security perspective to explicitly choose your own repos and not have dependencies bringing in artifacts from other ones
so i could see a malicious dependency bringing in artifacts that will push out other ones
@vikeri: I still have to extend the npm task to support more options, let me know what you run into and I can see what I can do
@flyboarder: Well now after some tinkering I have a pretty clear picture of what I need: To include my node_modules
folder and my test-runner.js
in the original fileset, then to compile cljs and add the resulting js-files to that fileset and ultimately run my testrunner with node (having access to all the files in the fileset). Not sure if that connects to your project but that is what I think I need at least.
Ok so my npm task can manage your node packages and put them into node_modules then it includes that folder in your output @vikeri
@flyboarder: Interesting, what advantage does that give compared to just managing it manually with npm?
It shells out to npm, so you get a few benefits, firstly you don't need any npm files in your source, everything is contained in boot file (as task options), modules are cached and moved to project folder so you don't need to redo load them, you also get the option of having multiple npm module lists, for different builds if needed, also since npm is underneath you get all the usual npm stuff @vikeri
@vikeri: right it's managed underneath for you
I added a new option so if your project uses bower, you can call the bower task and it will use the npm task to install itself then run
This will either be very helpful or adding unnecessary abstraction for the #C0E1SN0NM community. I think I have to have the node_modules
folder in sight for the RN packager but @pesterhazy is more suitable to see how this could be useful.
@vikeri: the folder should be available on the fileset after its run
So tasks which follow it don't know the difference
Hello! I'm using boot-cljs
and just upgraded to the lastest version of clojurescript (need :preloads) and now I get the following error in advanced compilation only:
> clojure.lang.ExceptionInfo: com.google.common.base.CharMatcher.javaUpperCase()Lcom/google/common/base/CharMatcher;
> data: {:file "/tmp/boot.user787106068256971973.clj", :line 19}
> java.lang.NoSuchMethodError: com.google.common.base.CharMatcher.javaUpperCase()Lcom/google/common/base/CharMatcher;
> com.google.javascript.jscomp.parsing.JsDocInfoParser.validTemplateTypeName JsDocInfoParser.java: 1216
Here are my boot.build versions
[org.clojure/clojure "1.9.0-alpha10"]
[org.clojure/clojurescript "1.9.89"]
[adzerk/boot-cljs "1.7.228-1"]
My boot version is 2.6.0
given that the other search hits on google point to a guava version mismatch, this is probably the culprit in my case: > [!] com.google.guava/guava > ✘ 19.0 > reagent > org.clojure/clojurescript > ✔️ 18.0 > com.cemerick/piggieback > org.seleniumhq.selenium/selenium-java > org.seleniumhq.selenium/selenium-remote-driver > org.seleniumhq.selenium/selenium-server