lumo

:lumo: Standalone ClojureScript environment. Currently at version 1.9.0
borkdude 2018-05-27T08:33:21.000015Z

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

anmonteiro 2018-05-27T08:33:49.000072Z

yeah :main is a namespace, not a variable

anmonteiro 2018-05-27T08:33:55.000053Z

:main 'foo.core

anmonteiro 2018-05-27T08:34:13.000075Z

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

borkdude 2018-05-27T08:35:06.000067Z

cool, it works now

borkdude 2018-05-27T08:35:35.000019Z

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

borkdude 2018-05-27T08:35:42.000077Z

thanks for the help

borkdude 2018-05-27T08:37:03.000081Z

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?

anmonteiro 2018-05-27T08:37:35.000042Z

@borkdude different people do different things 😛

anmonteiro 2018-05-27T08:37:51.000063Z

depends what you’re really trying to accomplish

anmonteiro 2018-05-27T08:38:07.000003Z

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

anmonteiro 2018-05-27T08:38:14.000002Z

Lumo allows for that too :party-corgi:

borkdude 2018-05-27T08:40:18.000054Z

cool, yeah, that works for a single file deploy

anmonteiro 2018-05-27T08:40:40.000078Z

yeah but it doesn’t bundle any NPM deps

borkdude 2018-05-27T08:40:48.000074Z

oh…

borkdude 2018-05-27T08:41:14.000070Z

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

anmonteiro 2018-05-27T08:43:06.000062Z

there is

anmonteiro 2018-05-27T08:43:21.000014Z

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

borkdude 2018-05-27T08:44:20.000042Z

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

borkdude 2018-05-27T08:44:43.000075Z

or maybe I misunderstood him…

anmonteiro 2018-05-27T08:46:50.000088Z

I don’t have a strong opinion

anmonteiro 2018-05-27T08:47:16.000026Z

single file may mean more optimizations

borkdude 2018-05-27T08:47:39.000079Z

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

anmonteiro 2018-05-27T08:47:58.000042Z

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

borkdude 2018-05-27T12:05:46.000011Z

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

borkdude 2018-05-27T12:06:00.000028Z

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

borkdude 2018-05-27T13:27:18.000031Z

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

borkdude 2018-05-27T13:45:33.000006Z

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

richiardiandrea 2018-05-27T16:14:11.000024Z

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

richiardiandrea 2018-05-27T16:14:33.000040Z

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

borkdude 2018-05-27T16:36:17.000003Z

Cool. I’ll try.

borkdude 2018-05-27T18:27:02.000049Z

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.
While browserify is callable from my shell. @richiardiandrea

borkdude 2018-05-27T18:36:23.000103Z

$ yarn global bin
/usr/local/bin

/usr/local/bin/browserify
# works

richiardiandrea 2018-05-27T18:45:44.000023Z

Yeah You have to install it ;)

borkdude 2018-05-27T18:57:10.000094Z

what do you mean?

richiardiandrea 2018-05-27T19:01:04.000099Z

@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

richiardiandrea 2018-05-27T19:01:12.000099Z

what you did above works as well though

richiardiandrea 2018-05-27T19:01:27.000132Z

but I don't like to install things globally 🙂

richiardiandrea 2018-05-27T19:01:52.000052Z

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

borkdude 2018-05-27T19:02:03.000069Z

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

richiardiandrea 2018-05-27T19:02:58.000007Z

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

borkdude 2018-05-27T19:03:23.000096Z

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

borkdude 2018-05-27T19:04:24.000123Z

$ 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"
  }
}

richiardiandrea 2018-05-27T19:04:25.000061Z

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

richiardiandrea 2018-05-27T19:04:29.000094Z

yeah that

richiardiandrea 2018-05-27T19:04:47.000004Z

the command yarn uglify should work now

richiardiandrea 2018-05-27T19:05:05.000045Z

and you should see it in node_modules/.bin

borkdude 2018-05-27T19:05:20.000016Z

oh these are two different things:

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

borkdude 2018-05-27T19:05:44.000066Z

ok, now I got:

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

borkdude 2018-05-27T19:06:15.000037Z

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

richiardiandrea 2018-05-27T19:06:57.000004Z

what error?

borkdude 2018-05-27T19:08:25.000011Z

the browserify step seems to work

👍 1
borkdude 2018-05-27T19:12:05.000108Z

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

TypeError: Cannot use 'in' operator to search for 'WEATHER_API_KEY' in undefined
I’ll try optimizations :simple

richiardiandrea 2018-05-27T19:12:45.000101Z

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

borkdude 2018-05-27T19:13:00.000081Z

that works

🎉 1
richiardiandrea 2018-05-27T19:13:28.000071Z

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

borkdude 2018-05-27T19:13:59.000101Z

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

richiardiandrea 2018-05-27T19:14:20.000076Z

I am not 100% sure but you might be right

richiardiandrea 2018-05-27T19:14:38.000063Z

I actually got the example from somewhere I cannot recall 😉

richiardiandrea 2018-05-27T19:15:58.000055Z

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

richiardiandrea 2018-05-27T19:16:19.000072Z

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

borkdude 2018-05-27T19:37:48.000023Z

@richiardiandrea might contribute when I get this script done

borkdude 2018-05-27T19:39:46.000010Z

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

borkdude 2018-05-27T19:45:32.000046Z

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

borkdude 2018-05-27T19:50:54.000004Z

@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

👌 1
borkdude 2018-05-27T19:51:01.000059Z

yields a slightly smaller script

anmonteiro 2018-05-27T20:01:12.000105Z

@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

anmonteiro 2018-05-27T20:01:33.000007Z

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

borkdude 2018-05-27T20:02:04.000009Z

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

borkdude 2018-05-27T20:07:21.000027Z

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]

borkdude 2018-05-27T20:08:05.000074Z

should *command-line-args* work there?

anmonteiro 2018-05-27T20:14:27.000005Z

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

anmonteiro 2018-05-27T20:14:44.000039Z

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

anmonteiro 2018-05-27T20:15:11.000074Z

by Clojure I mean clojure.main

anmonteiro 2018-05-27T20:15:23.000026Z

it captures the arguments after a “main option”

anmonteiro 2018-05-27T20:15:53.000006Z

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

anmonteiro 2018-05-27T20:16:15.000062Z

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

anmonteiro 2018-05-27T20:16:21.000047Z

brb lunch

borkdude 2018-05-27T20:26:38.000057Z

ah ok

borkdude 2018-05-27T20:52:56.000034Z

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

richiardiandrea 2018-05-27T21:34:55.000065Z

borkdude awesome! I think I will reference your repo when I will find the time for the wiki entry

richiardiandrea 2018-05-27T21:35:57.000103Z

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

richiardiandrea 2018-05-27T21:36:22.000029Z

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

richiardiandrea 2018-05-27T22:17:31.000069Z

This is expected behavior I think