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 😉
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 😛
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.
While browserify
is callable from my shell. @richiardiandrea$ 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 🙂
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 😉
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 😄
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
I’ll try optimizations :simple
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 😉
also if you want to kind of document it we have a 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
borkdude awesome! I think I will reference your repo when I will find the time for the wiki entry
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 ;)
This is expected behavior I think