Tools: Bundle is no longer optimized by default

[FredKSchott]

Moving to the analyze-first architecture gave us a much more stable library, but one side affect is that the bundle is now no longer optimized by default. Because the bundler asks the analyzer for files, it is getting the pre-optimized files the analyzer saw.

Workaround For Today

For bundled builds, optimize after bundling instead of before. This actually makes a lot more sense if you think about it, and now that the analyzer has moved there's no reason we can't. Potentially a long term solution if we update our docs.

Possible Solutions

• Workaround above
• Change the bundler to no longer ask the analyzer for files. Use the files that come through it instead.
• Add a new analyzer before the bundler that it can ask for files instead.

Thoughts

Unless anyone knows a good reason not to, I think the workaround for today is the best solution. Minifying and processing the code should happen in the end, and it makes more sense given our new analyze-first architecture. We'll still want to support users writing code that the analyzer cannot understand (bleeding edge JS with babel, TS, etc) but once it's through the analyzer successfully there's no reason we can't send it through the bundler as well.

/cc @justinfagnani @rictic @usergenic @Bubbit

[rictic]

+1 to the plan of optimizing after bundling. This will also give us the opportunity to integrate js+html module support into the bundler in a way that is transparent to any optimizers (have we considered calling that phase minifying rather than optimizing?).

[FredKSchott]

nice re: js+html module support! I hadn't even thought of that.

We leave that step pretty open ended for the user. So it can be minifying, or optimizing css for older browsers, or image optimizations, or basically any post-processing work the user might need. I'm all for finding a better name if one exists, but minifying is too narrow a definition imo.

[web-padawan]

+1 to optimizing after bundling. This is how we use polymer-build in our team right now:

1. polymer-build
2. gulp-htmlmin
3. gulp-crisper
4. gulp-uglify

[justinfagnani]

Initially I feel like the bundler should consume files that come via the stream. This is a more natural way for streams to work, and I've been very frustrated in the past when using transformers that ignore their input. Also, we can optimize once, then reuse the results. This will matter more the more permutations there are.

[justinfagnani]

Given input from #93 I'm leaning more towards thinking we need the bundler to support reading its files from the stream to support bundling post-optimizations. Actually, given that transforms could do arbitrary things to files, including renaming them, it's probably worth bundler, at least optionally, doing its own analysis.

[tony19]

@justinfagnani I agree. If I understand correctly, the bundler actually needs to consume files from the stream. Otherwise, it overwrites any previous transformations (undo-ing the work of minifiers), as seen in #110.

[justinfagnani]

@usergenic since you're rewriting the build/bundler interface, can you take a look at this?

[usergenic]

@justinfagnani will look into.

[usergenic]

https://github.com/Polymer/polymer-build/pull/144 should have fixed this. Forgot to close.