Skip to content
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

Webpack next per-source minification #169

Merged
merged 5 commits into from Dec 17, 2018

Conversation

guybedford
Copy link
Contributor

This implements #115 on top of #162, handling minification per-source, and therefore also caching minification per source.

The previous results it turns out were actually without minification due to #168. Here are the numbers with minification:

The build time summary of the self build here is:

  • With cache, with minification before this PR: First build 64s, Subsequent builds 47s
  • With cache, with minification after this PR: First build 64s, Subsequent builds 36s

@guybedford guybedford changed the base branch from master to webpack-next-cache December 17, 2018 20:33
@codecov-io
Copy link

codecov-io commented Dec 17, 2018

Codecov Report

Merging #169 into webpack-next-cache will increase coverage by 0.01%.
The diff coverage is 90%.

Impacted file tree graph

@@                  Coverage Diff                   @@
##           webpack-next-cache     #169      +/-   ##
======================================================
+ Coverage               73.32%   73.33%   +0.01%     
======================================================
  Files                      12       13       +1     
  Lines                     536      540       +4     
======================================================
+ Hits                      393      396       +3     
- Misses                    143      144       +1
Impacted Files Coverage Δ
src/index.js 93.25% <ø> (-0.43%) ⬇️
src/loaders/terser-loader.js 90% <90%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cf5cd9d...d6961cf. Read the comment docs.

@guybedford
Copy link
Contributor Author

Here's the difference in footprint on the self-build:

  • 2,691,197 bytes with per-source minification
  • 2,456,293 bytes with whole-file minification

the difference there is basically the wrappers not being minified - function (module, exports, __webpack_require__) sort of thing instead of function(a,b,c). There's no easy safe way to hack in the minification of the wrappers though unfortunately.

So the question then is the extra 10s on the self build (plus inability to parallelize) worth 100KB? I'd argue it might not be...

@rauchg
Copy link
Member

rauchg commented Dec 17, 2018

@guybedford I agree it's not. Keep in mind that once we investigate #51 I'm not even sure minification is worth it to begin with

@rauchg rauchg merged commit 35d0302 into webpack-next-cache Dec 17, 2018
@rauchg rauchg deleted the terser-loader-webpack-next branch December 17, 2018 21:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants