Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
add pure modules #5435
What kind of change does this PR introduce?
Did you add tests for your changes?
If relevant, link to documentation update:
Does this PR introduce a breaking change?
@sokra what do you think about changing the impl from looking at a
Which would mark that file and all dependencies beneath as pure. Gives a little more flexibility for the module author to contain side effects to specific places while allowing the rest of the codebase to be properly treeshaken.
The current template generates
This seems like a v2 feature, if at all. It's really bad practice to have side effects as part of an
Mind elaborating on what this "higher threshold" entails? The way I understand it, "pure" means:
Number 1 seems to be met due to the nature of ES modules. If I do
@danny-andrews it's not quite that cut and dry. Here's an example of some recent code:
We use styled-components at work and made a file that injects some global styles as soon as the module is interpreted. This is
However, the file is also consumed separately as one of the files fed into a webpack entry array; that case can't be wrapped in a callable function as webpack doesn't have a way of saying "load this file as an entry and call X function."
@danny-andrews , The value of
Regardless, whether an import statement is actually pure is not really relevant. The optimizations presented here rely on the lack of side effects within the modules. The overall effect will be people marking there packages/modules/etc. as "pure" when what they are actually doing (as per the documentation and code) is saying that there are no side effects within the aforementioned; and not that anything is indeed pure (true or otherwise). As a result, "pure" now equates with "no side effects". This may seem like a distinction without a difference. However and especially when dealing with optimizations, there is a difference. Also of relevance is Uglifyjs which appears to bare a similar concern.
Code splitting works as expected even for large modules like
This version also resolves the memory usage/leak issue I saw in the previous builds.
Lastly, it seems that module concat is working better now, which resulted in even smaller bundles.
Overall, this is the first build on this branch that seems to be working really well for our use-cases.
The only downside is initial build performance is slower because webpack has to crawl through many more files (previously we rolled-up small es modules into one big one, so it was faster for webpack to process it, but at that point we could no longer codesplit these large modules).
Sep 16, 2017
5 of 9 checks passed
referenced this pull request
Sep 25, 2017
added a commit
this pull request
Oct 20, 2017
This is fantastic! Thanks for the great work!
Part 1: Feature request
We have a large monorepo with many entry points. Within that repo we have a library of common React components that are used throughout the project. For convenience, we currently re-export almost every component from an index barrel. This necessarily causes every component to be bundled together, even though some entry points only use a small subset of them.
If we were able to mark that index barrel or the components that are re-exported as side-effect-free, we’d be able to leverage
Part 2: Advice request
If such a feature will not be implemented (or will not be implemented soon), is there a way to trick Webpack into thinking that internal collection of components is its own module? Perhaps adding a