Clojurians
#cljs-dev
<
2016-11-17
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

martinklepsch17:11:15

Maybe this is interesting for the "getting non Closure code through Closure" stuff: https://medium.com/@cramforce/introducing-splittable-1c882babca7e#.f3w5oujwq

martinklepsch17:11:05

It seems to do many of the things we'd want for properly integrating external libs into the build

martinklepsch17:11:49

@juhoteperi: ^

juhoteperi17:11:16

Hmm, what would that help?

juhoteperi17:11:22

Seems quite similar to using webpack/browserify + Cljs

martinklepsch18:11:16

Hm, I might not be aware of the full picture... just thought that the way it processes "foreign" modules might be of interest, if you think that's not helpful then it probably isnt :slightly_smiling_face: @juhoteperi

dnolen18:11:00

@martinklepsch it doesn’t seem like it’s different from what we’re already doing?

juhoteperi18:11:41

It uses browserify to turn CommonJS modules to code which browser can use, several Cljsjs packages do the same

juhoteperi18:11:53

Hmm, though it also uses Closure process commonjs modules option

martinklepsch18:11:56

@juhoteperi oh, so I think then I misunderstood. I thought all dependencies go through DCE + splitting as well (in Malte's splittable that is)

juhoteperi18:11:15

Maybe it uses browserify to turn ES6/NPM modules to CommonJS modules that Closure can process

dnolen18:11:07

It’s interesting but I suspect you still need externs for this to work

juhoteperi18:11:01

Splittable doesn't mention externs

martinklepsch18:11:15

@dnolen given that the premise of this project seems to be that "you can just use it" I'd be surprised if you're expected to supply externs

juhoteperi18:11:16

And doesn't define them in Closure options

juhoteperi18:11:46

Might be worth a try to test if Browserify can be used to convert npm "CommonJS" modules to CommonJS modules which Closure can process

dnolen18:11:04

I’m tweeting with Malte about this

dnolen18:11:12

we don’t have the full story yet

dnolen18:11:22

I suspect he may have separated DCE from renaming

dnolen18:11:43

in anycase - this isn’t going to magically solve the externs problem - whatever he’s done

juhoteperi18:11:33

It is possible he hasn't tried this with React or other "complex" libraries

martinklepsch18:11:23

I wonder if we could somehow get a "direct line" into the Closure team. So many things would be easier if you don't have to start by reading the source :smile: — "Priority Support"

dnolen18:11:33

@martinklepsch the mailing list is pretty good for the “direct line"

dnolen18:11:23

Malte did not fix the externs problem :slightly_smiling_face:

dnolen18:11:49

I think the ClojureScript community is probably the most advanced and well educated Closure consumers outside of Google itself :slightly_smiling_face:

martinklepsch18:11:30

but if I understand your tweet correctly externs are only required for "dynamic properties" and not for the majority of code?

dnolen18:11:46

@martinklepsch how is this different from today? :slightly_smiling_face:

dnolen18:11:11

everything that Malte described we can already do

dnolen18:11:21

we can already process CommonJS, AMD, and ES6

martinklepsch18:11:25

cljsjs-style-today or module-processing-today?

dnolen18:11:35

dead code elimination etc. all that stuff is working right now

martinklepsch18:11:38

yeah, so with processing there's no diff

dnolen18:11:22

to be clear the reason we can do this is because Malte did this work years ago :slightly_smiling_face:

dnolen18:11:24

and I asked him about it

dnolen18:11:37

he’s the reason we did the GSoC work - to improve it

dnolen18:11:31

Malte’s post is 5 years old

martinklepsch18:11:56

right :+1: heading to sleep, talk soon :wave: