Release - Document Version 3.0.0

[simon04]

Document changes according to https://github.com/webpack/webpack/releases/tag/v3.0.0

• updated to add the new 3.0 scope hoisting flag #1309
• docs(hmr): add requestTimeout option #1313
• docs(config/output): add libraryExport option #1314
• docs(output): update sourceMapFilename #1315
• docs(config/module): add function option for noParse #1316
• docs(config/node): add false for node option #1317
• docs(stats, cli): add new stats options #1320
• Scope Hoisting (Scope Hoisting webpack#4873)
• node_modules no longer mangle to ~ in stats, don't shorten node_modules to ~ webpack#4144 (if needed?)

[halfzebra]

There's also #4979 for noParse filtering function

[simon04]

That's already covered via #1316.

[skipjack]

@simon04 awesome! Thank you for tackling this with the rapid fire PRs! Starting to review/merge them now...

[skipjack]

Down to two... was scope hoisting tackled by #1309 or is it more of an overarching concept/feature we need to document? I'm happy to help push this forward if there's anything I can do.

[skipjack]

node_modules no longer mangle to ~ in stats, webpack/webpack#4144 (if needed?)

Is the only change just to the CLI output? Judging from the PR it looks like it. If so, I'd say this doesn't really require any changes. If anything we can go through the docs once things have stabilized a bit and updated all webpack bash output examples to the latest version.

[simon04]

was scope hoisting tackled by #1309 or is it more of an overarching concept/feature we need to document?

#1309 addressed the CLI change only. The changes in webpack/webpack#4873 seem to be larger than that, but I haven't investigated in detail yet. This example is relevant: https://github.com/webpack/webpack/tree/master/examples/scope-hoisting

---

node_modules no longer mangle to ~ in stats, webpack/webpack#4144 (if needed?)

Is the only change just to the CLI output?

I think so. It is considered a "breaking change" and thus listed in the release notes. I'm fine with not documenting this one.

[skipjack]

@sokra, or anyone else familiar with this new feature (cc @webpack/documentation-team), could you outline how this changes things for the end user so we can get it documented? I read through this example and webpack/webpack#4873, but still don't understand exactly what's changed in terms of usage.

[skipjack]

@kentcdodds hey I know you mentioned scope hoisting on gitter... any chance you'd be interested in helping document the changes and how they affect the end user? Even just a comment or two here would be appreciated...

[kentcdodds]

Unfortunately, my experience hadn't been what I expected. Upgrading to v3 increased my bundles by a few KB and adding the new plugin didn't change anything with the size. I expect that I've got something wrong, but I don't have time right now to figure out what or document the feature 😞

[TheLarkInn]

So from the users standpoint, not much will change for them.

I think there are two or three things to touch on.

• Turn it on with a plugin new webpack.optimize.ModuleConcatenationPlugin(), it is slower so use it in Production env's only.
• There are a few scenarios that webpack will "bail out" of these optimizations. They can be seen using the --display-optimization-bailout flag from CLI. These include a bunch of conditions that can be found in the plugin source.
• THIS IS A RUNTIME PERF FEATURE NOT SIZE PERF FEATURE <--- important to note. If folks would like to measure the effectiveness of the plugin, they should be calculating the runtime cost / execution time of their bundles before and after, not size before and after.

[kentcdodds]

THIS IS A RUNTIME PERF FEATURE NOT SIZE PERF FEATURE

Weird, I was under the impression that it would be both 🤔

[TheLarkInn]

In theory the overhead of fn calls would be stripped, you get a 1-10k win, but the real thing we want people to focus on is the real cost of all the functions which is the execution time.

I've just see a lot of people with radical expectations of cutting bundle size in half when really only 2% is module wrappers

[TheLarkInn]

And fwiw caps weren't focused at you Ken, just to emphasize that as a point I want explained in the clearest way possible lol. 😂

[kentcdodds]

I've just see a lot of people with radical expectations of cutting bundle size in half when really only 2% is module wrappers

Yeah, I've been surprised by all the tweets I've seen of people saying that it's cut the size of their bundles by a significant amount (like 30% or whatever). So you can imagine my disappointment when I saw that my bundle size actually went up. That was unexpected. I anticipated a slight decrease in size (like say, 2%? 😉). Still need to test runtime things out though...

[skipjack]

@TheLarkInn ok so --display-optimization-bailout is already documented in cli doc. I feel like points 1 and 3 can basically both be discussed in ModuleConcatenationPlugin page within /plugins:

Turn it on with a plugin new webpack.optimize.ModuleConcatenationPlugin(), it is slower so use it in Production env's only.

THIS IS A RUNTIME PERF FEATURE NOT SIZE PERF FEATURE <--- important to note. If folks would like to measure the effectiveness of the plugin, they should be calculating the runtime cost / execution time of their bundles before and after, not size before and after.

And maybe mentioned in /guides/production? Maybe this issue should be closed and we should open a more targeted issue that just discusses documenting that plugin?

[sokra]

Weird, I was under the impression that it would be both 🤔

@kentcdodds It looks like it decreases bundle size...

In some cases it really decreases bundle size, but only in rar cases where it helps the minimizer to do it's job.

It decreases minimized bundle size, but it doesn't affect gzipped bundle size that much.

This doesn't affect the download cost, but it affects the runtime cost for parsing the js in the browser. But the real benefit is the reduced number of functions (calls) at bootstrap.

Why does it affect the sizes in that way?

For the function scopes the minimized bundle behave this way:

- function(..){...},function(..){...},function(..){...},function(..){...},function(..){...},
+ function(..){..., ..., ..., ..., ...},

A lot of repeating can be gzipped great.

---

For the way of referencing exports from other modules the minimized bundle behaves this way:

- function(a,b){var c=b(17);Object(c.a)()},
- function(a,b){function c(){console.log("hello")}b.d(a,"a",function(){return c}}
+ function(){function c(){console.log("hello")}c()}

This is a clear size benefit, but with multiple exports per module it also compresses great because of repetition.

---

But there is also a bad thing for Scope Hoisting.

When concatenating 100 modules into one scope the number of identifiers in this scope also multiples by 100. Because of this the minimizer need to choose longer identifiers.

- a(),b(),c(),d()
+ zd(),ac(),au(),u()

This doesn't compress that well...

So the gzipped size can decrease or increase with Scope Hoisting.

[kentcdodds]

Thanks for explaining that @sokra 👍 makes sense!