Clojurians
#cljs-dev
<
2015-11-02
>

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

mfikes15:11:35

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

dnolen15:11:33

@mfikes: sounds like a good idea to me

mfikes15:11:23

@dnolen: Cool. I'll submit a JIRA and ultimately a patch. Thx!

razum2um18:11:53

@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

dnolen18:11:46

@razum2um: 1) 3) better answered by @maria

dnolen18:11:12

2) is just not that important IMO, there are lots of places in ClojureScript that could use refactoring

dnolen18:11:23

but we don’t touch stuff that works unless we need to

dnolen18:11:50

“refactor" is a synonym for “regression” :simple_smile:

razum2um18:11:58

interesting point, anyway got it, is @maria following the thread here?

dnolen18:11:44

she usually chimes in when she has time

razum2um18:11:15

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?

dnolen18:11:53

no I do not think that seamless integration with npm is worth pursuing

dnolen18:11:02

there’s just too many edge cases

dnolen18:11:47

however for now critical libraries like React it’s useful

dnolen18:11:05

for random npm things you might as well just use webpack to put that stuff together

razum2um18:11:01

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?

dnolen18:11:55

this has nothing to do with npm

dnolen18:11:44

some CommonJS things in NPM will work but we’re not going to spend any time building NPM integration

dnolen18:11:49

somebody else can figure that out

dnolen18:11:55

but’s not going to be standard feature

razum2um18:11:00

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

dnolen18:11:06

in theory it would be that easy, but the old NPM way effectively made that impossible

dnolen18:11:23

I don’t use Node.js or NPM at all except for REPL stuff

dnolen18:11:32

so I don’t know if NPM3 will fix the fundamental problem

razum2um18:11:55

what do you mean under “impossible” and "fundamental problem"?

juhoteperi18:11:24

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

juhoteperi18:11:39

NPM 3 will use flat dependencies if possible

juhoteperi19:11:29

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

dnolen19:11:10

Right but that also isn't practical for libraries not written with Closure in mind. React actually is.

maria21:11:35

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