Version v20161201 released

[Tyler Breisacher]

New compiler version now available on Maven, dl.google.com, and npm

https://github.com/google/closure-compiler/wiki/Releases

Not a whole lot of new stuff in this one:

* New type inference supports @abstract.

* Bugfixes in DisambiguateProperties for interface inheritance and implicit use of interfaces.

As always, let us know if you run into trouble (or unexpected happiness and joy) caused by the Closure Compiler, by starting a discussion here or opening a bug on GitHub.

Tyler

[Erik Neumann]

The NTI fix for @abstract is still not working for me, see comments I added to

https://github.com/google/closure-compiler/issues/104.

--ErikN

--

---
You received this message because you are subscribed to the Google Groups "Closure Compiler Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to closure-compiler-discuss+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/closure-compiler-discuss/CAH2y4KCOExUgwS4UZiitQ5EKCmt3n7tv8xz3NJAUSi2huguG%3Dg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Chad Killingsworth]

I forgot to add that CommonJS modules now use the node module resolution algorithm and support passing in JSON files as modules.

Also - Travis is choking on the NPM deploy. I'm trying to figure out why.

Chad Killingsworth

[Chad Killingsworth]

npm deployment is fixed now.

Chad Killingsworth

[Tyler Breisacher]

What was the problem? I think I just pushed the tag and forgot to double-check that it had actually finished publishing to npm.

--

---
You received this message because you are subscribed to the Google Groups "Closure Compiler Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to closure-compiler-discuss+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/closure-compiler-discuss/8136d15e-2dec-4550-bd19-569260cb5186%40googlegroups.com.

[Chad Killingsworth]

I had the deploy key encrypted with the old repo instead of the new one.

Chad Killingsworth

To unsubscribe from this group and stop receiving emails from it, send an email to closure-compiler-d...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/closure-compiler-discuss/CAH2y4KC2h%2BMapSBwTWfLgQQFjRZCGBwCb-9aLZdRc%3DgeRNthfw%40mail.gmail.com.

[David Nolen]

Node.js resolution for CommonJS module sounds like a great feature, but how are you able to take advantage of this? It seems you need to sort out all the CommonJS inputs under node_modules that should be passed to Closure on your own. Obviously, blindly adding all JS files under node_modules doesn't seem practical (or even likely to work).

Thanks,

David

--

---
You received this message because you are subscribed to the Google Groups "Closure Compiler Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to closure-compiler-discuss+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/closure-compiler-discuss/ac7a7da3-373c-434b-a35a-a94463251e6a%40googlegroups.com.

[Chad Killingsworth]

In general, this problem is left up to the build tool environment to solve.

• If you use the STRICT dependency management flag, you can on occasion get away with blindly adding the .js and package.json (you need both) files under node_modules.
  
• For the Java gulp and grunt plugins, I'm using the module-deps package to facilitate discovery of dependencies from a set of entry points. 

Chad Killingsworth

[David Nolen]

On Thu, Jan 26, 2017 at 1:41 PM, Chad Killingsworth <chad.kill...@banno.com> wrote:

In general, this problem is left up to the build tool environment to solve.

• If you use the STRICT dependency management flag, you can on occasion get away with blindly adding the .js and package.json (you need both) files under node_modules.
  
• For the Java gulp and grunt plugins, I'm using the module-deps package to facilitate discovery of dependencies from a set of entry points. 

Chad Killingsworth

Java gulp and grunt plugins? Haven't heard of that before. Googling didn't turn up anything obvious since gulp and grunt are way too popular :) Do you have a link handy?

Is this Java gulp & grunt plugin something you run via Node.js to compute some information and then pass on to Closure Compiler at the command line?

Thanks,

David

[Chad Killingsworth]

Java gulp and grunt plugins?

There are two different npm distributions: one that uses the java based compiler and one that is native JS. The Java based version is bundled with gulp and grunt plugins. That’s what I was referring to: https://github.com/google/closure-compiler-npm

Chad Killingsworth 

--

---
You received this message because you are subscribed to the Google Groups "Closure Compiler Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to closure-compiler-d...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/closure-compiler-discuss/CAPC9OadedQ1uU%2BgiQZMCABqkxOremc%2BWpCUu-r341HMb3WYn4A%40mail.gmail.com.

[David Nolen]

Thanks, module-deps looks really useful! But this seems specific to CommonJS modules? Given that ES6 Node Module resolution looks to be around the corner, do you have some other approach or is this unsolved?

David

On Thu, Jan 26, 2017 at 1:41 PM, Chad Killingsworth <chad.kill...@banno.com> wrote:

In general, this problem is left up to the build tool environment to solve.

• If you use the STRICT dependency management flag, you can on occasion get away with blindly adding the .js and package.json (you need both) files under node_modules.
  
• For the Java gulp and grunt plugins, I'm using the module-deps package to facilitate discovery of dependencies from a set of entry points. 

Chad Killingsworth

On Thursday, January 26, 2017 at 12:35:19 PM UTC-6, David Nolen wrote:

Node.js resolution for CommonJS module sounds like a great feature, but how are you able to take advantage of this? It seems you need to sort out all the CommonJS inputs under node_modules that should be passed to Closure on your own. Obviously, blindly adding all JS files under node_modules doesn't seem practical (or even likely to work).

Thanks,

David

On Tue, Dec 6, 2016 at 4:50 PM, Chad Killingsworth <chad.kill...@banno.com> wrote:

I forgot to add that CommonJS modules now use the node module resolution algorithm and support passing in JSON files as modules.

Also - Travis is choking on the NPM deploy. I'm trying to figure out why.

Chad Killingsworth

On Tuesday, December 6, 2016 at 2:59:37 PM UTC-6, Tyler Breisacher wrote:

New compiler version now available on Maven, dl.google.com, and npm

https://github.com/google/closure-compiler/wiki/Releases

Not a whole lot of new stuff in this one:

* New type inference supports @abstract.

* Bugfixes in DisambiguateProperties for interface inheritance and implicit use of interfaces.

As always, let us know if you run into trouble (or unexpected happiness and joy) caused by the Closure Compiler, by starting a discussion here or opening a bug on GitHub.

Tyler

--

---
You received this message because you are subscribed to the Google Groups "Closure Compiler Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to closure-compiler-discuss+unsubscr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/closure-compiler-discuss/ac7a7da3-373c-434b-a35a-a94463251e6a%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "Closure Compiler Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to closure-compiler-discuss+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/closure-compiler-discuss/47bc9221-6eee-49de-a5c4-85ab564540d7%40googlegroups.com.

[Chad Killingsworth]

No solution yet - mainly because I haven't spent any time on it. There are other options if you do a little searching.

Chad Killingsworth

To unsubscribe from this group and stop receiving emails from it, send an email to closure-compiler-discuss+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/closure-compiler-discuss/ac7a7da3-373c-434b-a35a-a94463251e6a%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[da...@ionic.io]

It would be really awesome to see the node module resolution algorithm implemented into Closure Compiler itself.

It would be awesome if we could just specify our entry point file and it could use the algorithm to properly identify all of the files to be includes, etc. With more and more libs distributing ES2015 modules instead of commonjs (Angular 4, for example), getting this support baked directly into closure would be a huge win both for Google and the broader web dev community.

Thanks,

Dan

[Chad Killingsworth]

The node module resolution IS being implemented in the compiler for ES6 modules. I think what you want is for the compiler itself to go discover the source files and add them to the compilation - that idea was definitely considered and rejected. The compiler does not "discover" and "add" files. This is pretty consistent with other compilers as well (uglify is the same last I checked).

This problem isn't as hard as you think. If you use dependency management flags in STRICT mode, the compiler will drop any file not referenced from an entry point. Dropping the file occurs VERY early in the process (although it still requires parsing). This is why blindly passing large sets of JS files to the compiler can actually work. You aren't even depending on dead code elimination. Internally the compiler traces through the module graph and any files not referenced are simply ignored. That functionality isn't new at all - it's been used by closure-library for several years and then was extended to work with modules about a year ago.

Chad Killingsworth