ClojureScript Is Not An Island: Integrating Node Modules

Re:ClojureScript Is Not An Island: Integrating Node Modules by swannodette on Wednesday July 12, 2017 @04:37PM (#14756433)

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 question isn't relying on string-based meta programming everything should work.

Granted this rules out some libraries, there are plenty of libraries written in a simple straightforward style that will work just fine. In particular I am bullish about fantastic results with ES6+ libraries written with ES6 classes with static import/export. Closure will eat that stuff up.

[ Parent | on HN ]

Re:ClojureScript Is Not An Island: Integrating Node Modules by sjrd on Wednesday July 12, 2017 @06:40PM (#14757295)

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 externs).

[ Parent | on HN ]

Re:ClojureScript Is Not An Island: Integrating Node Modules by Scarbutt on Wednesday July 12, 2017 @07:25PM (#14757547)

how does interop works in scalajs without externs?

[ Parent | on HN ]

Re:ClojureScript Is Not An Island: Integrating Node Modules by sjrd on Thursday July 13, 2017 @12:23AM (#14758681)

The Scala.js compiler, thanks to its static types, precisely knows which property accesses refer to "internal" properties (defined in Scala code, which can be renamed) and which ones refer to external JavaScript code (which cannot). It then simply always emit the former using dot notation (foo.bar) and the latter with bracket notation (foo["bar"]). This allows Closure to rename all internal property accesses but not external property accesses.

It's even slightly more powerful than using externs: if you use the same property name both in internal accesses and external ones, Scala.js can rename the former without touching the latter. An externs-based solution won't be allowed to rename the internal accesses.

[ Parent | on HN ]

Re:ClojureScript Is Not An Island: Integrating Node Modules by anmonteiro90 on Wednesday July 12, 2017 @04:46PM (#14756515)

Just to add to this statement, even in cases where externs will still be necessary, adding CLJSJS packages[1] to your project's classpath will result in those externs being used even if you don't use the libraries that the packages provide.

http://github.com/cljsjs/packages

[ Parent | on HN ]

Re:ClojureScript Is Not An Island: Integrating Node Modules by spicyj on Thursday July 13, 2017 @01:14AM (#14758893)

What were those four names?

[ Parent | on HN ]

Re:ClojureScript Is Not An Island: Integrating Node Modules by anmonteiro90 on Thursday July 13, 2017 @01:29AM (#14758940)

He was referring to these https://github.com/cljsjs/packages/blob/950064853c8391ac7a88...

[ Parent | on HN ]