This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (15)
- # aws (35)
- # beginners (6)
- # boot (183)
- # cider (51)
- # clara (17)
- # cljs-dev (32)
- # clojure (67)
- # clojure-dev (7)
- # clojure-india (1)
- # clojure-japan (3)
- # clojure-norway (1)
- # clojure-russia (26)
- # clojurescript (85)
- # clojurex (4)
- # community-development (1)
- # cursive (18)
- # data-science (1)
- # datomic (46)
- # devcards (29)
- # events (7)
- # funcool (21)
- # hoplon (10)
- # ldnclj (2)
- # lein-figwheel (16)
- # off-topic (60)
- # om (37)
- # onyx (8)
- # re-frame (23)
- # reagent (5)
- # yada (6)
@dnolen: I'm pondering the appropriateness of a patch to
cljs.js that allows self-host clients to enable
:static-fns true. Thought I'd mention the idea here to let it stew.
@dnolen: hi, I read about gsoc and deal with commonjs modules loading, thanks to you and mneise.
1) what do you think about allow to specify
:language-in for every of
:foreign-libs here https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/closure.clj#L1297 from corresponding options
convert-js-module :es6 and
convert-js-module :commonjs seems to share a lot code, what do you think about some drying?
3) I carefully followed what happened in july to closure-compiler: now
es6-loader accepts multiple roots, so what do you think about scanning all path for nodejs modules and allow to include them transparently
2) is just not that important IMO, there are lots of places in ClojureScript that could use refactoring
just wanted to ask, do you think what seamless integration with nodejs and its modules is a good idea
e.g. I mean if we have on npm A depending on B -> currently we should list both under
:foreign-libs, what about zero-configuration
require [node-package] in code what will just work?
so when decide between “we start support some npm cases for critical packages at least and let people build a foreign-lib from what fails” vs “no support at all, let people wait/build for cljsjs package for the newer version" you go with the second?
some CommonJS things in NPM will work but we’re not going to spend any time building NPM integration
> some CommonJS things in NPM sure, that’s what I mean. if package and it’s deps are done right - let just require it and it’s deps seamlessy?
Probably related to how NPM installs dependencies "recursively", i.e. dependencies A and B could depend on different version of library C and NPM would install different version of C for A and B
In any case, most or all NPM projects are available as jars from Webjars so it would be cool to have tooling support those instead of packaging everything ourselves like we do with Cljsjs
Right but that also isn't practical for libraries not written with Closure in mind. React actually is.
@razum2um: regarding 1), allowing a
ES6ModuleLoader which could add support for node js require statements and which would probably change the interface of the loader, so I would prefer to wait for the outcome of those discussions (https://groups.google.com/forum/#!topic/closure-compiler-discuss/4SpP-o7HKBk)