google/closure-compiler-js

Webpack API / compatibility

swernerx opened this issue · 3 comments

swernerx commented

I was trying to integrate Closure Compiler to my Advanced Boilerplate.

My setup currently looks super simple:

      ifProdClient(new ClosureCompilerPlugin({
        options: {
          compilationLevel: "SIMPLE"
        }
      })),

I have some kind of factory producing the actual webpack config. That's the reason why there is the ifProdClient() call.

Effects I saw:

  • A ton of outputs (=hundreds) regarding some 3rd party dependencies I include about some JSDoc comments (I don't care about) e.g. main-LeExkXKk.js:19675 (JSC_PARSE_ERROR) Parse error. illegal use of unknown JSDoc tag "category"; ignoring it @category Lang without mentioning any source file (wouldn't it be useful to reverse map based on the existing source map?)

  • A lot of messages regarding "JSC_UNREACHABLE_CODE" - I figure these are mostly regarding some conditionals based on process.env in the original code which are evaluated into true/false in the compiled code.

  • No support for my vendor chunk. Maybe this is some kind of parse error as their are other messages e.g. warnings coming from the processing of the vendor package. But the output file is just the Webpack original code. The only error message here looks like: vendor-QRGMGbNu.js:29608 (JSC_INVALID_NO_SIDE_EFFECT_ANNOTATION) @nosideeffects may only appear in externs files. render: 'DEFINE_ONCE',

  • I wonder about unreachable code for catch clauses. How could it actually figure this out?

  • Duplicated polyfills and infrastructure in different places. There should be definitely an option to prevent adding these. I either use Babel polyfill / Babel helper or some remote service like polyfill.io. I definitely don't want to bake all these things into my code. And definitely not into every chunk again.

  • It does not seem to "like" the "default" export handling of Webpack: main-LeExkXKk.js:9704 (JSC_USELESS_CODE) Suspicious code. This code lacks side-effects. Is there a bug? return !(0, _deepEqual2.default)(this.props, nextProps);

I wish, based on what I read, Closure Compiler JS would be in a better state. Right now it seems that there are so many issues, in such a simple boilerplate project, that I could not suggest anyone from the typical Webpack users to care about.

I wonder if there is actually any progress happening on improving the situation.

It does not help to claim that something could be used as some kind of drop-in replacement (presentations/conferences) to Uglify/Babili when even the most basic things are not working. Some good ES6 compatible (input and output) compressor would be really appreciated.

As far as I understand this project it's basically cross-compiled from Java. If these issues are more about the original Java implementation, feel free to forward them.

swernerx commented

BTW: This is the source code for the vendor chunk:

import "intl"
import "isomorphic-fetch"

import "react"
import "react-dom"
import { BrowserRouter } from "react-router"
import "react-intl"

nothing special.

rondonjon commented

Hello @swernerx, you could work around points 1 and 2 in your original post if CC would use the webpack API to raise its errors and warnings instead of just dumping them to stdout. Since you're using webpack2 with a big configuration, I guess you're already processing webpack's error and warning arrays at some point, and you could then at least suppress these meaningless messages. See pull request #70