This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-11-17
Channels
- # aws (3)
- # beginners (81)
- # boot (155)
- # capetown (2)
- # cider (32)
- # clara (14)
- # cljs-dev (40)
- # cljsrn (12)
- # clojure (158)
- # clojure-austin (5)
- # clojure-korea (6)
- # clojure-poland (1)
- # clojure-russia (63)
- # clojure-spec (45)
- # clojure-uk (75)
- # clojurescript (109)
- # code-reviews (1)
- # core-logic (12)
- # core-matrix (1)
- # cursive (36)
- # datomic (16)
- # defnpodcast (1)
- # devcards (2)
- # editors (3)
- # euroclojure (1)
- # events (3)
- # flambo (1)
- # hoplon (19)
- # javascript (4)
- # jobs (1)
- # lein-figwheel (4)
- # leiningen (1)
- # off-topic (1)
- # om (177)
- # onyx (121)
- # pedestal (14)
- # planck (19)
- # proton (3)
- # re-frame (36)
- # reagent (21)
- # remote-jobs (1)
- # ring (4)
- # ring-swagger (6)
- # spacemacs (1)
- # specter (2)
- # test-check (4)
- # untangled (9)
- # utah-clojurians (1)
- # yada (2)
Maybe this is interesting for the "getting non Closure code through Closure" stuff: https://medium.com/@cramforce/introducing-splittable-1c882babca7e#.f3w5oujwq
It seems to do many of the things we'd want for properly integrating external libs into the build
Hmm, what would that help?
Seems quite similar to using webpack/browserify + Cljs
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 🙂 @juhoteperi
@martinklepsch it doesn’t seem like it’s different from what we’re already doing?
It uses browserify to turn CommonJS modules to code which browser can use, several Cljsjs packages do the same
Hmm, though it also uses Closure process commonjs modules option
@juhoteperi oh, so I think then I misunderstood. I thought all dependencies go through DCE + splitting as well (in Malte's splittable
that is)
Maybe it uses browserify to turn ES6/NPM modules to CommonJS modules that Closure can process
Splittable doesn't mention externs
@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
And doesn't define them in Closure options
Might be worth a try to test if Browserify can be used to convert npm "CommonJS" modules to CommonJS modules which Closure can process
in anycase - this isn’t going to magically solve the externs problem - whatever he’s done
It is possible he hasn't tried this with React or other "complex" libraries
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 😄 — "Priority Support"
@martinklepsch the mailing list is pretty good for the “direct line"
I think the ClojureScript community is probably the most advanced and well educated Closure consumers outside of Google itself 🙂
but if I understand your tweet correctly externs are only required for "dynamic properties" and not for the majority of code?
@martinklepsch how is this different from today? 🙂
cljsjs-style-today or module-processing-today?
yeah, so with processing there's no diff
right 👍 heading to sleep, talk soon 👋