Polymer 2.0 Build Permutations and Improvements

[FredKSchott]

• Create single build instead of bundle & unbundle builds as default [polymer-test] error with Chrome 66 and 67 #509
• --bundle build flag [polymer-test] error with Chrome 66 and 67 #509
• rename --insert-dependency-links to --insert-prefetch-links [WCT] Mocha slow api is ineffective  #510
• --js-compile build flag [wct] {clientOptions: environmentScripts } can't be overriden anymore #525
• replace uglify with babili [wct] {clientOptions: environmentScripts } can't be overriden anymore #525
• --add-service-worker build flag [WCT] Corrected environment scripts handling #534
• reintroduce multiple builds via polymer.json named builds Fix audit warnings in build #545
• decide what default build case should be. All off? (Design Doc)
• make sure we have a good migration story. Which options to continue to support? (Design Doc)
• Cleanup changelog Fix audit warnings in linter #551
• add helpful message to "UNKNOWN_OPTION" error (optional, if there are issues with the next release)
• Add stronger build unit & integration tests (to do later)
• --polyfill=['none'|'partial'|'full'] build flag

[yordis]

@FredKSchott will this allow me to add .babelrc in my project and it will use it? So I can add babel-preset-env if I want.

Also, could you add autoprefixer and allow me to add the browserlist in my project so I can configure the output?

[yordis]

Btw, it will be great if I can define either babelrc or browserlist in the command line so we can support multiple builds. Example: polymer build --babelrc="path/here" --browserlist="path/here"

For example, one of my case I have to support IE11, but I don't want to ship the same version of the Javascript file for the modern browsers. They have almost 100% of ES6 support, so the trade off is big 😢

[FredKSchott]

@yordis supporting multiple builds is the plan (see list above).

Once this is done we can look into supporting the ability to pass in your own .babelrc file. We really want to support that, but it's a bit of a foot-gun because the modules transform that is a part of es2015 preset causes a breaking change to the top-level scope of each file.

[yordis]

@FredKSchott I didn't understand the concern about the module transform.

Also, you don't need to even pass the .babelrc as a parameter, you could check the pwd for the .babelrc but if I am not mistaking with the proper Babel setup it should do it for you.

This is the Babel code
https://github.com/babel/babel/blob/9c2794dc85af9ed1aa6bd319ba279d04fb34e392/packages/babel-core/src/transformation/file/options/build-config-chain.js#L54

[justinfagnani]

Modules and classic scripts have differences that cause problems when interpreting a script as module. The one I already hit in some testing libraries is that top-level this is undefined in modules.

The compilation feature might make more sense when you view it as leveling the language features available supported browsers, not providing configurable language transforms like Babel in general. We want to be able to send uncompiled source to the latest browsers, so we can't support features that they don't.