@johnjelinek which scaffolding are you talking about exactly? Maybe I can help. You use javascript libraries transparently using npm install
(or yarn
) and then you require
them in your code. Pretty much like JS.
@richiardiandrea: ok, I think I'm able to answer this a little better now. I've translated some step definitions for cucumber-js
from .js
to .cljs
, so my tree looks like this:
$ tree features
features
├── documentation.feature
├── step_definitions
│ ├── browser_steps.cljs
│ └── hooks.cljs
└── support
└── world.cljs
so -- to build, I think I want to do something like this:
$ lumo -c features build.clj
but my out/
doesn't seem to have any of the transpiled .js
step_definitions.because after it builds, I want to do something like:
./node_modules/.bin/cucumber-js out
So the compilation is not something that is done using the above lumo command: lumo was born as REPL and then added a compiler
maybe my files aren't being transpiled in out
because they don't have a namespace?
ie: world.cljs
(js/require "chromedriver")
(def seleniumWebdriver (js/require "selenium-webdriver"))
(def defineSupportCode (.-defineSupportCode (js/require "cucumber")))
(defn custom-world []
(this-as this
(let [builder (new (.-Builder seleniumWebdriver))
forBrowser (.forBrowser builder "chrome")]
(set! (.-driver this) (.build forBrowser)))))
(defineSupportCode
#(% ((.-setWorldConstructor %) custom-world)))
So yeah, they are not
In order to do that, you have to build: use lumo.build.api
. There is no doc at the moment but you can easily follow the ClojureScript one
Let me fetch a link for you
here's my build.clj
:
(require 'lumo.build.api)
(lumo.build.api/build "features"
{:output-to "out/main.js"
:target :nodejs
:optimizations :none
:language-out :es6})
Oh ok cool
Sorry so the problem is elsewhere, why is it build.clj
?
Usually those are macro files
I'd try build.cljs
just to be sure
I was following the cljs Quick Start
¯\(ツ)/¯
if I do the hello world
example in the Quick Start
(`hello-world.core`) and put a :main
in build.clj
, it transpiles it and I can run it in node/lumo
so I'm thinking maybe I'm missing a namespace entry that allows it to transpile these files in features/
Uhm not sure that's an issue
or maybe I need to do some kind of file-globbing reference to get it to pick up all the folders with .cljs
files in it
No well the folder should be fine, if it contains .cljs
files they should be picked up bugs aside. I would try the namespace thing just to be sure..
About Javascript interop, there is minimal syntax to learn, then after that you should be good
this can be of help: http://www.spacjer.com/blog/2014/09/12/clojurescript-javascript-interop/
cool, I'll check it out -- right now I'm trying to translate some of the cucumber
JS examples into CLJS and then I'll see if cucumber
(CLI) can pick up the changes in my out
directory
correct me if I'm wrong, but lumo
still requires the JDK to build, because of Boot
, correct?
to build lumo itself, yes
it'd be pretty cool to have Boot written in cljs
as well so there's only a dependency on a single node runtime
IMHO doesn't seem worth it just for the convenience of people interested in hacking on lumo itself
ya, but it sure would give me some boilerplate for my own non-JDK cljs project
question: if I'm going to build a non-trivial application, I'll prolly implement something like boot
just like lumo
does -- and if I do that, then I'll already have a dependency on the JDK -- so, why go with lumo
to compile my cljs
at that point instead of depending on the JDK that boot
uses?
@johnjelinek you gave yourself a pretty good question 😄 Personally I really believe that there should be a non-JVM workflow for working in ClojureScript and I adopted lumo
in order to completely avoid building with it. So far I am only rarely using boot
or lein
when I add a new Clojure dependency and build using yarn
(`scripts` section calls a small bash script). I use JS deps from npm as much as I can. If you need a fully fledged build tool with no JVM have a look at calvin
. Also make sure to read Antonio's blog posts about the compiler: it is there, but it's got some limitation being quite a recent port of the Google Closure Compiler. I have found and reported some (and solved?), but I am ok with it because I support 100% the project, things are not super super smooth yet.