4 ms·

This feature is really, really a long time coming. Myself and other ClojureScript core contributors are happy to answer any questions people may have.

Royalaid 9y ago
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 https://github.com/webrtc/adapter) and as a result a ton of externs. It would be cool if I could just plug and play!
- swannodette 9y ago
  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.
  - anmonteiro90 9y ago
    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 http://github.com/cljsjs/packages
  - sjrd 9y ago
    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).
    - Scarbutt 9y ago
      how does interop works in scalajs without externs?
      - sjrd 9y ago
        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.
  - spicyj 9y ago
    What were those four names?
    - anmonteiro90 9y ago
      He was referring to these https://github.com/cljsjs/packages/blob/950064853c8391ac7a88dbb87be7187fc17a8a62/react/resources/cljsjs/react/common/react.ext.js#L1834-L1840 https://github.com/cljsjs/packages/blob/950064853c8391ac7a88...
yanivtal 9y ago
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.
- anmonteiro90 9y ago
  We shell out to `npm` to install the dependencies you specify, so I don't see why it wouldn't work.
  - yanivtal 9y ago
    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?
    - anmonteiro90 9y ago
      strings in `:npm-deps` should just work. I'm more concerned about the npm syntax for `@namespace/package@version` which I'm not sure is valid. If it doesn't work though, please open a ticket so we can fix it!
jgalt212 9y ago
any stats on how many of the top X npm packages get through the Closure compiler unscathed?

Royalaid 9y ago

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 https://github.com/webrtc/adapter) and as a result a ton of externs. It would be cool if I could just plug and play!

swannodette 9y ago
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.
- anmonteiro90 9y ago
  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 http://github.com/cljsjs/packages
- sjrd 9y ago
  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).
  - Scarbutt 9y ago
    how does interop works in scalajs without externs?
    - sjrd 9y ago
      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.
- spicyj 9y ago
  What were those four names?
  - anmonteiro90 9y ago
    He was referring to these https://github.com/cljsjs/packages/blob/950064853c8391ac7a88dbb87be7187fc17a8a62/react/resources/cljsjs/react/common/react.ext.js#L1834-L1840 https://github.com/cljsjs/packages/blob/950064853c8391ac7a88...

yanivtal 9y ago

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.

anmonteiro90 9y ago
We shell out to `npm` to install the dependencies you specify, so I don't see why it wouldn't work.
- yanivtal 9y ago
  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?
  - anmonteiro90 9y ago
    strings in `:npm-deps` should just work. I'm more concerned about the npm syntax for `@namespace/package@version` which I'm not sure is valid. If it doesn't work though, please open a ticket so we can fix it!

jgalt212 9y ago

any stats on how many of the top X npm packages get through the Closure compiler unscathed?