Fork me on GitHub
#cljs-dev
<
2017-02-04
>
bhauman15:02:48

@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?

bhauman15:02:20

ie. a dependency that adds a bunch of common babel js transformations to the closure/js-transforms multimethod?

bhauman15:02:45

maybe it makes sense to just hold the babel js code there and other libs could reference it

bhauman15:02:27

I've just been thinking about how JSX transforms will be a common need

juhoteperi15:02:50

Though I wonder how common JSX transform needs well be? React libs in npm will contain processed code.

juhoteperi15:02:03

I guess it will be useful for people converting projects from JS to Cljs?

bhauman15:02:38

There's the need to for JSX inside of projects

bhauman15:02:54

something the designers can work with

juhoteperi15:02:13

In my experience designers can as well write Reagent hiccup syntax as they can write JSX

bhauman15:02:25

I agree completely

juhoteperi15:02:03

But yeah, there will be cases where that won't be possible for some reason

bhauman15:02:03

but ... that doesn't meet the needs of those who don't agree

bhauman15:02:15

absolutely

bhauman15:02:35

Plus its a bomber feature

bhauman15:02:47

that CLJS can do JS better than JS

bhauman15:02:10

at conferences you can demonstrate insane JS hotloading

bhauman15:02:21

stuff they really struggle to do in JS

juhoteperi15:02:55

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

bhauman15:02:53

yes parametrizing it can be done by the dev in user.clj

bhauman15:02:59

if they have to

bhauman15:02:28

but supplying :cljsjs/jsx-2016

bhauman15:02:38

as a default would be super helpful

bhauman15:02:15

and maybe a helper ??? to use in the user.clj

bhauman15:02:42

(add-babel-transform :something babel args)

juhoteperi15:02:07

hmm, the js-transforms method gets the ijs map as argument, so it could also build the options from there

juhoteperi15:02:38

{:file "src" :module-type :es6 :preprocess :cljsjs/babel :babel-opts {:presents [:react :es2016]}} or something

bhauman15:02:36

that's interesting

bhauman15:02:55

but it would also be nice to have the default tranform

bhauman15:02:15

which is probably 99.9% of the cases

juhoteperi15:02:00

sure, {:presets [:react :es2016]} could be the default and user could override those

bhauman15:02:44

how about :cljsjs/babel-opts ??

bhauman15:02:07

that would be freaking sweet 🙂

bhauman15:02:34

think about how cool it would be to just pop out into es6 and whip something out

bhauman15:02:52

because of some crazy interop pattern

bhauman15:02:24

or you have a JSX react component that you just want to use whole hog

bhauman15:02:41

and not translate it

bhauman15:02:40

or you just want to try some found snippet of code out before you translate it to CLJS

juhoteperi15:02:54

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.

bhauman15:02:45

but there is the case of the :jvm-opts ^:replace ["-Xmx1g" "-server"]

bhauman15:02:20

I haven't played around with it enough to know why that is required

bhauman15:02:06

Want to be careful requiring that

juhoteperi15:02:43

Xmx sets the maximum heap size

bhauman15:02:47

yeah it doesn't look like a problem

juhoteperi15:02:53

I think the default is 25% of system memory, for me that is 16GB

bhauman15:02:34

hmmm so I'm guessing nashorn is a resource hog

juhoteperi15:02:04

But I think most users have over 4GB memory so -Xmx1g would shrink the limit instead of increasing it

bhauman15:02:44

It seems that you may prefer to not require nashorn and babel to process small libs

juhoteperi15:02:26

I think build time processing is better option for Cljsjs libs

bhauman15:02:56

and this cljsjs/babel would help with that as well ... 🙂

juhoteperi15:02:10

Hmm true, it would probably be possible to replace some cases where currently webpack or babel is used through node

juhoteperi15:02:29

Though, if package provides it's own webpack configuration, it is best to use that

bhauman15:02:49

yay this is exciting

bhauman18:02:07

hmmm the emacs temp files with the form ".#asdf.js" in commonjs modules are causing problems

bhauman18:02:18

the compiler should ignore these no?

bhauman18:02:23

Should we enforce that files name should start with a #"\w"? Or is that too much?

dnolen18:02:08

@bhauman we actually already do that for watch

bhauman18:02:42

Yeah but I think this is caused by the foreign lib module dir expansion

dnolen18:02:39

@bhauman: yeah so I’m just saying it’s fine to fix this 🙂

dnolen18:02:51

we don’t want to include temp Emacs files

dnolen18:02:56

and a lot of Clojure users are Emacs users

bhauman18:02:13

Is it true that first character of file names has to match #"\w"

dnolen18:02:21

hrm I don’t know about that

dnolen18:02:27

no desire to make this general

dnolen18:02:36

I would just copy the specific Emacs workaround adopted in watch

thheller19:02:06

@bhauman temp files like emacs or vim are typically hidden

thheller19:02:20

you can test that with java

thheller19:02:25

File.isHidden or so

bhauman19:02:37

very interesting

thheller19:02:38

(what I do in shadow-build)

bhauman19:02:59

this is a good point

bhauman19:02:32

@dnolen does File.isHidden work for you?

bhauman19:02:45

I have patch that works with that

juhoteperi23:02:39

I tested this with the example from Cljs site