21–30 of 43 posts
This feature is really, really a long time coming. Myself and other ClojureScript core contributors are happy to answer any questions people may have.
This is huge. Very excited for this! Is there support for private NPM repos? NPM looks for the registry URL and auth token in ~/.npmrc and uses that to authenticate.
Earlier quoted context omitted.
I fail to see how Closure Complier is any more complicated, more painful, and has any more caveats than Babel/Webpack. With Closure Compiler at 8 years old and building some of the most sophisticated JS properties on the web (GDocs anyone?) it seems pretty "solid" to me. Perhaps it not clear from the post but that's a big part of why this works, we're not doing the heavy lifting.
Its not about closure, is all the Clojurescript interop issues/gotchas, what's the correct way to do interop today in Clojurescript?
Scary, any newbie will read this and run away. Is passing through the complexity, pain and all the caveats one can encounter from this really worth it for using Clojurescript? Serious question, now that with have ES6+ and today babel/webpack are solid tools. I mean from all the modules mess, I didn't get what's the correct way to do javascript interop right now.
Earlier quoted context omitted.
It sounds like this handles extern inference if possible. Is that the case? I have wanted to play around with Webrtc for a while now but it basically requires adapter.js ( https://github.com/webrtc/adapter ) and as a result a ton of externs. It would be cool if I could just plug and play!
There's no extern inference required here as all the original sources are passed directly through Google Closure Compiler. As a benchmark for feasibility when we started we chose React.js as it's non-trivial and heavily depended upon in the ClojureScript ecosystem. We discovered that over all of React's sources we only need 4 extern definitions for 4 generated names in EventsPlugin. So as long as the JS library in qu…
Anyway, congrats on those features :-) Scala.js doesn't do the part where Closure is applied on JS dependencies; it's only applied to Scala.js code (though with the advantage that we never need any externs).
Earlier quoted context omitted.
This is huge. Very excited for this! Is there support for private NPM repos? NPM looks for the registry URL and auth token in ~/.npmrc and uses that to authenticate.
We shell out to `npm` to install the dependencies you specify, so I don't see why it wouldn't work.
Earlier quoted context omitted.
We shell out to `npm` to install the dependencies you specify, so I don't see why it wouldn't work.
Sweet. Looks like it should work then. The only problem is that private npm repos use a @namespace/package format. I don't think :@namespace/package would be valid. Looks like you support strings for requires. Do you also support strings for :npm-deps?
[1] https://hackernoon.com/how-it-feels-to-learn-javascript-in-2...
This is a great step for ClojureScript. It's extremely difficult for a compile-to-JS language to bootstrap a large enough ecosystem to stand alone. A good interop story neatly sidesteps that issue.
Earlier quoted context omitted.
There's no extern inference required here as all the original sources are passed directly through Google Closure Compiler. As a benchmark for feasibility when we started we chose React.js as it's non-trivial and heavily depended upon in the ClojureScript ecosystem. We discovered that over all of React's sources we only need 4 extern definitions for 4 generated names in EventsPlugin. So as long as the JS library in qu…
That's a surprisingly positive result. Usually I expect most JavaScript libraries to be destroyed by Closure's Advanced optimizations, unless they've been written specifically with Closure in mind (which they're not). Anyway, congrats on those features :-) Scala.js doesn't do the part where Closure is applied on JS dependencies; it's only applied to Scala.js code (though with the advantage that we never need any exte…