ok, now I got:

(require 'lumo.build.api)

(lumo.build.api/build "src"
                      {:target :nodejs
                       :main 'foo.core/main
                       :output-to "out/main.js"})

(ns foo.core)

(defn main []
  (println (+ 1 2 3)))

(set! *main-cli-fn* main)

$ lumo -c src build.cljs && node out/main.js
goog.require could not find: foo.core.main

yeah :main is a namespace, not a variable

:main 'foo.core

there’s really no difference in configuration between the Lumo compiler and the CLJS compiler

cool, it works now

yeah, it’s just that I have 0 experience with node and I try it again like once a year :wink:

thanks for the help

when you deploy a node script to a server, is it common to make a single script out of it and scp it or npm install the libs on the server in the project dir?

@borkdude different people do different things :stuck_out_tongue:

depends what you’re really trying to accomplish

(in any case I’d suggest compiling with optimizations :advanced)

Lumo allows for that too :party-corgi:

cool, yeah, that works for a single file deploy

yeah but it doesn’t bundle any NPM deps

oh…

so there’s nothing quite like an uberjar in cljs/node world?

there is

you can use webpack / rollup / favorite bundler of the month

I tried shadow-cljs and there the author said it wasn’t common to make a single file for deploys, that’s why I wanted your opinion. Maybe building on the server is the most convenient

or maybe I misunderstood him…

I don’t have a strong opinion

single file may mean more optimizations

I tried planck but I needed an e-mail library. lumo seems to be more suited, because at least you have the plethora of npm libs

but I think people do deploy servers and npm install inside docker containers or whatever they’re using

lumo uses self-hosted cljs right? how does it evaluate macros defined in .clj? I’m surprised it works

although macro inference didn’t work, I got it working using :require-macros

what’s a nice http lib to use with node? I tried cljs-ajax but I get

WARNING: poppea$macros is a single segment namespace at line 1 poppea.clj
No such namespace: cljs.edn, could not locate cljs/edn.cljs, cljs/edn.cljc, or JavaScript source providing “cljs.edn” in file poppea.clj

ok maybe just this: https://gist.github.com/yogthos/d9d2324016f62d151c9843bdac3c0f23#file-gallery-cljs-L11

done porting my script to lumo! https://github.com/borkdude/balcony

Just for reference, I was producing a single JS file with the following: https://github.com/paullucas/les-clj/blob/master/scripts/build#L14

But I am not JS Expert at all so there are probably 100 other ways to do that

Cool. I’ll try.

I’m trying:

yarn global add uglifyjs
yarn global add browserify
yarn -s browserify --node --standalone index $COMPILED_PATH \
  | yarn -s uglifyjs --preamble '#!/usr/bin/env node' -o $BUNDLED_PATH
error Command "browserify" not found.
error Command "uglifyjs" not found.

$ yarn global bin
/usr/local/bin

/usr/local/bin/browserify
# works

Yeah You have to install it ;)

what do you mean?

@borkdude you need to add it to your local package json with yarn add uglify and yarn add browserify -> https://github.com/paullucas/les-clj/blob/master/package.json#L43-L46

what you did above works as well though

but I don't like to install things globally :slightly_smiling_face:

yarn uglify calls the locally installed version of the package (it is an JS convenience)

I know. I only installed it globally, because I got the same error locally.

oh ok, in your example I saw only global installs, and you said you were not familiar with node, sorry :wink:

yes, I’m still not, so thanks for helping me

$ cat package.json
{
  "dependencies": {
    "moment": "^2.22.1",
    "nodemailer": "^4.6.5",
    "npm": "^6.1.0"
  },
  "devDependencies": {
    "browserify": "^16.2.2",
    "uglifyjs": "^2.4.11"
  }
}

I am learning slowly as well, I actually like many of the convenient things the JS tooling offer you :smile:

yeah that

the command yarn uglify should work now

and you should see it in node_modules/.bin

oh these are two different things:

“uglify”: “^0.1.5",
    “uglifyjs”: “^2.4.11"

ok, now I got:

“devDependencies”: {
    “browserify”: “^16.2.2”,
    “uglify”: “^0.1.5”
  }

cool, it seems to work now (although I get a different error)

what error?

the browserify step seems to work

but the resulting js doesn’t execute properly. I get:

TypeError: Cannot use 'in' operator to search for 'WEATHER_API_KEY' in undefined

yeah, try :simple, I had some discussion with David about compiling node with :advanced and he strongly believes it is not worth it

that works

so I am thinking of making the whole process you just went through smoother

the browserified version works, so single file is working. uglify is only for compression of the size of the file right?

I am not 100% sure but you might be right

I actually got the example from somewhere I cannot recall :wink:

also if you want to kind of document it we have a wiki :wink:

https://github.com/anmonteiro/lumo/wiki

@richiardiandrea might contribute when I get this script done

hmm, it seems the browserified script doesn’t receive the *command-line-args* correctly

ok, it seems that browserify outputs some dialect of JS that uglify didn’t understand, so I tried uglify-es which worked

@richiardiandrea tip:

yarn add uglifyify
echo '#!/usr/bin/env node' > $BUNDLED_PATH
chmod +x $BUNDLED_PATH
yarn -s browserify -g uglifyify --node --standalone index $COMPILED_PATH >> $BUNDLED_PATH

yields a slightly smaller script

@borkdude probably late to the party, but if you wanna make sure you JS runs faster with :simple there are some other options that might come in handy

e.g. :elide-asserts true, :static-fns true, :fn-invoke-direct true

cool, I’ll try them out, after I get the command line args working in the compiled one

ah, after compiling with :simple, I print *command-line-args* and process.argv:

$ node out/main.js -m
*command-line-args* nil
process.argv #js [/usr/local/Cellar/node/10.2.1/bin/node /Users/Borkdude/Dropbox/dev/clojure/balcony/lumo/out/main.js -m]

should *command-line-args* work there?

@borkdude no. *command-line-args* is for scripts that you start with Lumo

it has the same semantics as Clojure’s *command-line-args*

by Clojure I mean clojure.main

it captures the arguments after a “main option”

so like lumo -c your-classpath-here -vK myScript.cljs --one-option --other-option

in this case *command-line-args* would be '("--one-option" "--other-option")

brb lunch

ah ok

Deployed to VPS! Documented + scripts here: https://github.com/borkdude/balcony/tree/master/lumo

The interesting thing is that even without compilation the script should run way faster than the jvm

Not very interesting actually...we all know that ;)