This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-11-02
Channels
- # 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.
Self-host static-fns JIRA: http://dev.clojure.org/jira/browse/CLJS-1478
@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
2) 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
NPM 3 will use flat dependencies if possible
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 :language-in
option for each module could be useful for some and is actually planned for enhanced module support (https://github.com/clojure/clojurescript/wiki/Enhanced-JavaScript-Module-Support). regarding 3), there is some discussion on the Google Closure mailing list about rewriting the 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)