This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-02-04
Channels
- # arachne (2)
- # bangalore-clj (3)
- # beginners (34)
- # boot (22)
- # cider (1)
- # cljs-dev (86)
- # cljsjs (3)
- # clojure (42)
- # clojure-argentina (6)
- # clojure-austin (10)
- # clojure-chicago (1)
- # clojure-france (3)
- # clojure-russia (135)
- # clojure-spain (1)
- # clojure-uk (4)
- # clojurescript (69)
- # core-async (13)
- # cursive (11)
- # datascript (6)
- # datomic (8)
- # dirac (2)
- # emacs (10)
- # euroclojure (1)
- # events (1)
- # gsoc (13)
- # jobs-rus (9)
- # lumo (7)
- # off-topic (18)
- # om (16)
- # perun (3)
- # planck (1)
- # portland-or (1)
- # re-frame (25)
- # ring (22)
- # spacemacs (1)
- # untangled (14)
@juhoteperi do you think it makes sense to add something like a babel transforms lib (ie. https://clojurescript.org/guides/javascript-modules#babel-transforms) to cljsjs?
ie. a dependency that adds a bunch of common babel js transformations to the closure/js-transforms
multimethod?
maybe it makes sense to just hold the babel js code there and other libs could reference it
Though I wonder how common JSX transform needs well be? React libs in npm will contain processed code.
I guess it will be useful for people converting projects from JS to Cljs?
In my experience designers can as well write Reagent hiccup syntax as they can write JSX
But yeah, there will be cases where that won't be possible for some reason
I don't know much about this stuff, but looking at the guide, looks like babel-standalone could be packaged as cljsjs/babel-standalone
and it would contain babel.min.js
, and perhaps a namespace that creates the engine
? Not sure about the multimethod as the Babel options need to be provided somehow
hmm, the js-transforms
method gets the ijs
map as argument, so it could also build the options from there
{:file "src" :module-type :es6 :preprocess :cljsjs/babel :babel-opts {:presents [:react :es2016]}}
or something
sure, {:presets [:react :es2016]}
could be the default and user could override those
or you just want to try some found snippet of code out before you translate it to CLJS
Cljsjs packages could also use preprocessing nearly transparently, a package could depend on babel and deps.cljs
could refer the preprocess method. Though user would still need to require the namespace to setup multimethod.
Xmx sets the maximum heap size
I think the default is 25% of system memory, for me that is 16GB
But I think most users have over 4GB memory so -Xmx1g
would shrink the limit instead of increasing it
I think build time processing is better option for Cljsjs libs
Hmm true, it would probably be possible to replace some cases where currently webpack or babel is used through node
Though, if package provides it's own webpack configuration, it is best to use that
hmmm the emacs temp files with the form ".#asdf.js" in commonjs modules are causing problems
I tested this with the example from Cljs site