This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-01-29
Channels
- # aws (1)
- # aws-lambda (1)
- # beginners (34)
- # boot (61)
- # cljs-dev (126)
- # cljsjs (10)
- # cljsrn (4)
- # clojure (27)
- # clojure-russia (7)
- # clojure-spec (1)
- # clojure-uk (26)
- # clojurescript (42)
- # cursive (31)
- # datascript (4)
- # datomic (16)
- # hoplon (51)
- # klipse (1)
- # lein-figwheel (1)
- # lumo (79)
- # off-topic (16)
- # om (7)
- # parinfer (5)
- # planck (2)
- # re-frame (6)
- # reagent (3)
- # ring-swagger (5)
- # untangled (11)
@npeckman @malcolmsparks was the discussion about publishing cljs code on npm?
(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 )
Yeah @shaunlebron we were talking about publishing code
Maybe all we need is a Lumo registry 🙂
half-joking. I'm not a big fan of fragmentation
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
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
are folks only publishing transpiled es5 to npm?
i just checked node_modules/react
and it all looks transpiled
i’d say it only makes sense to publish es5 to npm, but to keep cljs dependencies on maven
the problem is that tools like planck/lumo have to handle dependencies like this: http://planck-repl.org/dependencies.html
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?
@shaunlebron I'd say every popular library is publishing ES5 to NPM
ES5 as opposed to what?
as opposed to ES6
ES2015-2017, and JSX, Flow, all kinds of stuff
I'm sure some people who don't know exactly what they're doing might publish ES6 stuff 🙂
but that just creates a hard dependency for everyone downstream to use ES6
@malcolmsparks tagged literals for cljs should be published on maven, do you know how to do that?
Yes, I think so. What's the rationale (over clojars, npm)
oops, I meant clojars
the rationale for not publishing to npm is that people don’t do it yet
Right.
so people using lein or boot wouldn’t be able to pull in your tagged literals
But people publish uncompiled cljs to clojars don't they?
yes, it’s clojure source files packed into a jar (zip)
these get added to the java classpath so they’re compiled with your clojurescript project
I'm keen not to neutralise all the effort gone into lumo and its superfast startup by throwing my uncompiled stuff to compile
In the end user's time/cpu
I agree we should have a way to publish "aot" artifacts for Lumo/Planck to consume
that way loading them would just be loading javascript
When we end up building the whole tower again on lumo, in uncompiled form, aren't we back where we started?
but we'd have to do some of that ground work in Lumo
but it's definitely a good idea
we'd need a way to output not only JS from CLJS but also the analysis cache
I’m not familiar with how “aot” works for cljs files
that's what the CLJS compiler needs to consume in order to know which vars are in which namespaces
I'm totally behind publishing Aero to clojars for lein/boot users
But I'm happy publishing JS to npm too. (And Mach is getting to be capable enough to automate these chores for me)
Makes sense @anmonteiro
How to publish the AC?
👍 aot cljs => js + analysis cache
sounds like that’s what needs figuring out
exactly
I think you can do that today manually with:
lumo -k cache_folder
and then requiring your namespace in Lumo
the compiled JS and analysis cache will be in the cache folder
probably!
Would compiling to js take away any analysis & development (e.g. autocompletion) capabilities from the future away?
@dominicm it wouldn't as long as you provide the analysis cache
the analysis cache is what goes into the ClojureScript compiler environment, it's how it knows that a namespace has certain vars
and more stuff of course, the arities of functions, etc
@anmonteiro what would read the analysis cache? Would new tooling need building around it?
Lumo would consume the analysis cache and dump it into the CLJS compiler environment
I mean, that's how it works today
the only piece missing is probably just tell Lumo to look for AOTed namespaces in JARs it consumes
@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?
I suppose you could say that, yes
That sounds perfect for going in then, and completely quenches my concerns about the general concept of aot'ing cljs.
ClojureScript already does that for cljs.core
, if you use the :classifier "aot"
artifact from Maven
Interesting. Do you happen to know if that's a heavy source of compilation time in many projects?
it is
@dominicm the analyzer is what does most of the work in the CLJS compiler
for published artifacts it should be OK
for development time of your own stuff it's not
I guess this is also where boot loses in performance for some clojurescript, as it throws away caches regularly.
cached analysis during development means you won't get arity errors, undeclared vars, etc
Interesting, so this is aot’ing the clojure into bytecode and the cljs into js+analysis?
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.)
^ that's right, forgot about this one
The compiled JavaScript also reflects build affecting options, like whether to use static functions or whether asserts have been elided.
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.
Maybe this has never mattered much for JVM ClojureScript given Closure is usually used.
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.
wonder if packages could publish an aot for each cljs version