Note: the viewer needs additional changes to its build script to emit a map. This only emits a map for LR, the extension, and DT.

some changes....

there's an extra space in the fn declaration for modules:

not obvious why the devtools bundle got so much bigger (+ 504KB on disk).

Here's the visual bundle:

Can't do the same for "base"/master, because this tool requires a source map :)

got a visual bundle from the previous process of browserify -> babel (ccf966d).

as you can see, "unmapped" went up a lot.

the answer is in here somewhere... (diff b/wn dt bundles) https://gist.github.com/connorjclark/c80ca014042950ff0dd15ee23fcb6f42

Must be related to the babel version bump. I think it's related to "minifying" with a transform during browserify, instead of processing the output of browserify.

The culprit is the browserify builtins. They don't get processed by the babelify transform - so comments, whitespace, all remain.

Here where we're at:

We do browserify -> babel. Bundle is 1.6M. Babel's job is just to reduce the size of the script (via retain_lines and compact). Great when their were two passes. However, emitting source maps with this two-pass compilation created off-by-one issues.

Moving babel into browserify via babelify is cool, but it missed out on minimizing the builtins that browserify injects. This adds ~0.3M to the devtools bundle.

We could completely remove the line retaining minimization, and just use Terser. This save ~0.4MB. Source maps are perfect in this two-pass compilation. Terser handles input maps better than babel, apparently.

I asked @patrickhulce about the utility of "retain lines" in the bundle output. He said it originated from wanting "readable" diffs when rolling to DevTools. I wonder if that is a behavior we should bother keeping?

He said it originated from wanting "readable" diffs when rolling to DevTools

yeah that and the moderately improved stack trace is a nice feature of retainLines, but I'm not sure how much we need either at this point. I can't remember the last time we got a legit bug report where the bundled stack trace was useful. If we had a mechanism (script?) that could easily translate a stack trace using our sourcemap, saving 0.5MB sounds like a steal to me.

If we had a mechanism (script?) that could easily translate a stack trace using our sourcemap, saving 0.5MB sounds like a steal to me.

covered! https://www.npmjs.com/package/stack-beautifier

npx stack-beautifier -t <file_with_stack.txt> <app.js.map>

I like getting rid of yet another minifier in our deps :)

Did we figure out the serving thing, though? My main thing is probably the occasional stepping through LH in devtools and the current formatting does make that actually viable without a source map.

Agreed with Patrick that it's pretty rare I find myself actually doing that, but then again that means what use are source maps? :)

Did we figure out the serving thing, though? My main thing is probably the occasional stepping through LH in devtools and the current formatting does make that actually viable without a source map.

For devtools / Lightrider, you can attach source maps from a URL, which you would get by checking out the correct sha, building, and starting a local server in dist ... I think that's the best solution we have.

But don't forget the viewer - it's trivial to use maps there.

Worth noting: we have no tests that utilize the output of our bundled code (ala how React tests their lib). We might do good to run the smoke tests on the bundled code (#9501 references how).