Fork me on GitHub
#lumo
<
2018-05-27
>
borkdude08:05:21

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

anmonteiro08:05:49

yeah :main is a namespace, not a variable

anmonteiro08:05:55

:main 'foo.core

anmonteiro08:05:13

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

borkdude08:05:06

cool, it works now

borkdude08:05:35

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

borkdude08:05:42

thanks for the help

borkdude08:05:03

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?

anmonteiro08:05:35

@borkdude different people do different things 😛

anmonteiro08:05:51

depends what you’re really trying to accomplish

anmonteiro08:05:07

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

anmonteiro08:05:14

Lumo allows for that too party-corgi

borkdude08:05:18

cool, yeah, that works for a single file deploy

anmonteiro08:05:40

yeah but it doesn’t bundle any NPM deps

borkdude08:05:14

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

anmonteiro08:05:21

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

borkdude08:05:20

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

borkdude08:05:43

or maybe I misunderstood him…

anmonteiro08:05:50

I don’t have a strong opinion

anmonteiro08:05:16

single file may mean more optimizations

borkdude08:05:39

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

anmonteiro08:05:58

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

borkdude12:05:46

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

borkdude12:05:00

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

borkdude13:05:18

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

richiardiandrea16:05:11

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

richiardiandrea16:05:33

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

borkdude16:05:17

Cool. I’ll try.

borkdude18:05:02

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

borkdude18:05:23

$ yarn global bin
/usr/local/bin

/usr/local/bin/browserify
# works

richiardiandrea18:05:44

Yeah You have to install it ;)

borkdude18:05:10

what do you mean?

richiardiandrea19:05:04

@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

richiardiandrea19:05:12

what you did above works as well though

richiardiandrea19:05:27

but I don't like to install things globally 🙂

richiardiandrea19:05:52

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

borkdude19:05:03

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

richiardiandrea19:05:58

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

borkdude19:05:23

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

borkdude19:05:24

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

richiardiandrea19:05:25

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

richiardiandrea19:05:47

the command yarn uglify should work now

richiardiandrea19:05:05

and you should see it in node_modules/.bin

borkdude19:05:20

oh these are two different things:

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

borkdude19:05:44

ok, now I got:

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

borkdude19:05:15

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

borkdude19:05:25

the browserify step seems to work

👍 4
borkdude19:05:05

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

richiardiandrea19:05:45

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

borkdude19:05:00

that works

🎉 4
richiardiandrea19:05:28

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

borkdude19:05:59

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

richiardiandrea19:05:20

I am not 100% sure but you might be right

richiardiandrea19:05:38

I actually got the example from somewhere I cannot recall 😉

richiardiandrea19:05:58

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

borkdude19:05:48

@richiardiandrea might contribute when I get this script done

borkdude19:05:46

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

borkdude19:05:32

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

borkdude19:05:54

@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

👌 4
borkdude19:05:01

yields a slightly smaller script

anmonteiro20:05:12

@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

anmonteiro20:05:33

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

borkdude20:05:04

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

borkdude20:05:21

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]

richiardiandrea22:05:31

This is expected behavior I think

borkdude20:05:05

should *command-line-args* work there?

anmonteiro20:05:27

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

anmonteiro20:05:44

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

anmonteiro20:05:11

by Clojure I mean clojure.main

anmonteiro20:05:23

it captures the arguments after a “main option”

anmonteiro20:05:53

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

anmonteiro20:05:15

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

richiardiandrea21:05:55

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

richiardiandrea21:05:57

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

richiardiandrea21:05:22

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