Clojurians Log v2

@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

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?

@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

$ lumo -c features build.clj

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

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