-
-
Notifications
You must be signed in to change notification settings - Fork 3.3k
update tree shaking guide for webpack 4 #1865
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
cc @sokra I think uglify isn't technically needed anymore to do tree shaking right? But seems like a good recommendation to enable it anyway. |
Thanks @probablyup, can you change the base from |
@jeremenichelli done |
@@ -144,7 +144,7 @@ In this setup, `index.js` explicitly requires `lodash` to be present, and binds | |||
With that said, let's run `npx webpack` with our script as the [entry point](/concepts/entry-points) and `bundle.js` as the [output](/concepts/output). The `npx` command, which ships with Node 8.2 or higher, runs the webpack binary (`./node_modules/.bin/webpack`) of the webpack package we installed in the beginning: | |||
|
|||
``` bash | |||
npx webpack src/index.js dist/bundle.js | |||
npx webpack src/index.js --output dist/bundle.js |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not sure where this change came from...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From the next
rebase maybe.
src/content/guides/tree-shaking.md
Outdated
## Minify the Output | ||
## Mark the file as side-effect-free | ||
|
||
In a 100% ESM module world, identifying side effects is straightforward. However, we don't live in that reality just yet, so it's necessary to provide hints to webpack's compiler on the "pureness" of your code. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you rephrase we don't live in that reality just yet, so
to we aren't there just yet, in the mean time
src/content/guides/tree-shaking.md
Outdated
|
||
Let's start by installing it: | ||
T> A "side effect" is defined as code that performs a special behavior when imported, other than simply exposing one or more exports. For instance: a polyfill which adjusts the global scope but does not provide an export or has one that you are not using in your codebase. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we rephrase this as:
A "side effect" is defined as code that performs a special behavior when imported, other than exposing one or more exports like a polyfill, which might affect the global scope and might not provide an export or has one that you are not using in your codebase.
src/content/guides/tree-shaking.md
Outdated
## Minify the Output | ||
|
||
So we've cued up our "dead code" to be dropped by using the `import` and `export` syntax, but we still need to drop it from the bundle. To do that, we'll use the `-p` (production) webpack compilation flag to enable the uglifyjs minification plugin. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@TheLarkInn @sokra is the -p flag still recommended in webpack 4? Or should we clarify that is for versions older than v4?
## Conclusion | ||
|
||
So, what we've learned is that in order to take advantage of _tree shaking_, you must... | ||
|
||
- Use ES2015 module syntax (i.e. `import` and `export`). | ||
- Add a "sideEffects" entry to your project's `package.json` file. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would be if the code is not affecting outside scope, not always so we should add it to here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually no, you should always add a sideEffects entry or treeshaking won't work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, but if your librari does produce side effects you shouldn't, right? I don't want to give that message to package owners.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps, but in that case set it to true
, or provide an array with the specific files that include side effects as described in the guide.
It's better to explicitly have the sideEffects known to webpack than to try and infer it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is required?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe is redundant since you already define what sideEffects
means. I'm OK with it. Sorry for the noise.
There are some rephrasing that I think is necessary, the rest looks good @probablyup |
cdae9d0
to
6194853
Compare
@jeremenichelli updated |
Do you think it's worth also linking to the debugging optimization bailouts section from this page? |
I think this should also include:
|
00a5bd2
to
9ad350d
Compare
@edmorley updated |
@jeremenichelli could this be merged? I think many people would find it helpful |
@probablyup this is great - thank you for the changes :-) |
updated the treeshaking documentation for webpack 4