This page is not created by, affiliated with, or supported by Slack Technologies, Inc.


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


About Javascript interop, there is minimal syntax to learn, then after that you should be good


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?


@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

├── 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)))))

  #(% ((.-setWorldConstructor %) custom-world)))


So yeah, they are not


In order to do that, you have to build: use 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 '

( "features"
  {:output-to "out/main.js"
   :target :nodejs
   :optimizations :none
   :language-out :es6})


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


to build lumo itself, yes


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


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


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


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 :smile: 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.