Fork me on GitHub
#lumo2017-01-29
>
shaunlebron19:01:44

@npeckman @malcolmsparks was the discussion about publishing cljs code on npm?

shaunlebron19:01:20

(sorry, invited @logbot so chat can be logged here without breaking the clojurian-wide 10k message limit https://clojurians-log.clojureverse.org/lumo/index.html )

npeckman19:01:57

Yeah @shaunlebron we were talking about publishing code

anmonteiro19:01:24

Maybe all we need is a Lumo registry 🙂

anmonteiro19:01:45

half-joking. I'm not a big fan of fragmentation

malcolmsparks20:01:30

Node + Cljs (via lumo) could be a massive benefit. Cljs is a much better language than JS, so bringing cljs to a much wider audience could be a big win. But only if the extensions story is worked out. And you don't often get the chance to discuss trade offs ahead of time

malcolmsparks20:01:59

So I'm really keen to see some views here, especially from those with prior JS experience. I don't have any strong opinions here myself

shaunlebron20:01:53

are folks only publishing transpiled es5 to npm?

shaunlebron20:01:12

i just checked node_modules/react and it all looks transpiled

shaunlebron20:01:48

i’d say it only makes sense to publish es5 to npm, but to keep cljs dependencies on maven

shaunlebron20:01:59

the problem is that tools like planck/lumo have to handle dependencies like this: http://planck-repl.org/dependencies.html

malcolmsparks20:01:11

I'd really like guidance on this. I'm keen to publish a cljs version of juxt's aero (config) tag literals (for edn). But should I precompile first? And where to publish?

anmonteiro20:01:21

@shaunlebron I'd say every popular library is publishing ES5 to NPM

malcolmsparks20:01:57

ES5 as opposed to what?

anmonteiro20:01:17

as opposed to ES6

shaunlebron20:01:24

ES2015-2017, and JSX, Flow, all kinds of stuff

anmonteiro20:01:43

I'm sure some people who don't know exactly what they're doing might publish ES6 stuff 🙂

anmonteiro20:01:06

but that just creates a hard dependency for everyone downstream to use ES6

shaunlebron20:01:23

@malcolmsparks tagged literals for cljs should be published on maven, do you know how to do that?

malcolmsparks20:01:12

Yes, I think so. What's the rationale (over clojars, npm)

shaunlebron20:01:37

oops, I meant clojars

shaunlebron20:01:30

the rationale for not publishing to npm is that people don’t do it yet

shaunlebron20:01:10

so people using lein or boot wouldn’t be able to pull in your tagged literals

malcolmsparks20:01:11

But people publish uncompiled cljs to clojars don't they?

shaunlebron20:01:35

yes, it’s clojure source files packed into a jar (zip)

shaunlebron20:01:15

these get added to the java classpath so they’re compiled with your clojurescript project

malcolmsparks20:01:47

I'm keen not to neutralise all the effort gone into lumo and its superfast startup by throwing my uncompiled stuff to compile

malcolmsparks20:01:09

In the end user's time/cpu

anmonteiro20:01:34

I agree we should have a way to publish "aot" artifacts for Lumo/Planck to consume

anmonteiro20:01:51

that way loading them would just be loading javascript

malcolmsparks20:01:06

When we end up building the whole tower again on lumo, in uncompiled form, aren't we back where we started?

anmonteiro20:01:11

but we'd have to do some of that ground work in Lumo

anmonteiro20:01:22

but it's definitely a good idea

anmonteiro20:01:47

we'd need a way to output not only JS from CLJS but also the analysis cache

shaunlebron20:01:02

I’m not familiar with how “aot” works for cljs files

anmonteiro20:01:04

that's what the CLJS compiler needs to consume in order to know which vars are in which namespaces

malcolmsparks20:01:04

I'm totally behind publishing Aero to clojars for lein/boot users

malcolmsparks20:01:55

But I'm happy publishing JS to npm too. (And Mach is getting to be capable enough to automate these chores for me)

malcolmsparks20:01:04

How to publish the AC?

shaunlebron20:01:12

👍 aot cljs => js + analysis cache

shaunlebron20:01:28

sounds like that’s what needs figuring out

anmonteiro20:01:50

I think you can do that today manually with:

lumo -k cache_folder

anmonteiro20:01:06

and then requiring your namespace in Lumo

anmonteiro20:01:19

the compiled JS and analysis cache will be in the cache folder

dominicm20:01:13

Would compiling to js take away any analysis & development (e.g. autocompletion) capabilities from the future away?

anmonteiro20:01:42

@dominicm it wouldn't as long as you provide the analysis cache

anmonteiro20:01:19

the analysis cache is what goes into the ClojureScript compiler environment, it's how it knows that a namespace has certain vars

anmonteiro20:01:35

and more stuff of course, the arities of functions, etc

dominicm20:01:44

@anmonteiro what would read the analysis cache? Would new tooling need building around it?

anmonteiro20:01:31

Lumo would consume the analysis cache and dump it into the CLJS compiler environment

anmonteiro20:01:39

I mean, that's how it works today

anmonteiro20:01:08

the only piece missing is probably just tell Lumo to look for AOTed namespaces in JARs it consumes

dominicm20:01:45

@anmonteiro is my understanding correct that the analysis cache is a lossless step that is pre-js and is the bulk of the compilation time to generate?

anmonteiro20:01:47

I suppose you could say that, yes

dominicm20:01:22

That sounds perfect for going in then, and completely quenches my concerns about the general concept of aot'ing cljs.

anmonteiro20:01:43

ClojureScript already does that for cljs.core, if you use the :classifier "aot" artifact from Maven

dominicm20:01:17

Interesting. Do you happen to know if that's a heavy source of compilation time in many projects?

anmonteiro20:01:53

@dominicm the analyzer is what does most of the work in the CLJS compiler

dominicm20:01:54

I may just start using that everywhere. Unless there's a drawback I'm not seeing?

anmonteiro20:01:14

for published artifacts it should be OK

anmonteiro20:01:22

for development time of your own stuff it's not

dominicm20:01:34

I guess this is also where boot loses in performance for some clojurescript, as it throws away caches regularly.

anmonteiro20:01:40

cached analysis during development means you won't get arity errors, undeclared vars, etc

shaunlebron20:01:53

Interesting, so this is aot’ing the clojure into bytecode and the cljs into js+analysis?

mfikes21:01:51

A problem with including AOT artifacts in published JARs is that the artifacts are tied to a compiler version. (The ClojureScript compiler ignores them on a version mismatch.)

anmonteiro21:01:18

^ that's right, forgot about this one

mfikes21:01:00

The compiled JavaScript also reflects build affecting options, like whether to use static functions or whether asserts have been elided.

mfikes21:01:34

Perhaps shipping libs could be built in "release" mode, enabling both options, and the broader issue of version compatibility could be solved in some way.

mfikes21:01:26

Maybe this has never mattered much for JVM ClojureScript given Closure is usually used.

dominicm21:01:25

That's a fairly big drawback!

mfikes21:01:51

Since Lumo and Planck (and any self-hosted implementation) can cache, I suppose the issue isn’t huge—you can take the hit of compilation only on first hit when using a library, and then after that things are fast.

shaunlebron21:01:33

wonder if packages could publish an aot for each cljs version