No dead code elimination during snowpack build, with plugin-webpack

[ralphtheninja]

I get the following warning in the browser console from React when building with snowpack build and using @snowpack/plugin-webpack:

I mentioned this in the Discord chat and @drwpow said this shouldn't be happening.

I'm also seeing the following from babel during build:

[snowpack] ! building source…
[snowpack] ✔ build complete [1.56s]
[snowpack] ! installing dependencies…
[snowpack] ✔ install complete [20.94s]
[BABEL] Note: The code generator has deoptimised the styling of 
/home/rtn/src/snowpack-app/build/web_modules/common/index-24963793.js as it exceeds the max of 500KB.

Unsure if this is related or not.

I've done some research into why babel echoes this and I believe it's related to the compact setting for babel being set to "auto". However, I have no idea where this configuration is set. I know that plugin-babel does its job for each file, but I'm guessing this babel step somehow comes after when webpack is bundling the code.

Site note: I'm using [email protected] because environment variables are broken in latest version, but this problem remains in the latest version.

EDIT: This doesn't seem to be related to webpack at all, since we can reproduce it with a plain snowpack build, without using plugin-webpack.

[FredKSchott]

Fixed the "compat" issue quickly in #1031, but I'm still not sure where that "dead code" elimination issue is coming from.

[ralphtheninja]

but I'm still not sure where that "dead code" elimination issue is coming from.

Supposedly, according to React, it's related to the TerserPlugin(), https://reactjs.org/docs/optimizing-performance.html, but this is being used in plugin-webpack already. So I'm stumped on this as well.

[ralphtheninja]

A side note. I suddenly realized while testing with other browsers than Firefox that this error is only shown if you have React Developer Tools addon installed. Otherwise React is completely silent about it.

[ralphtheninja]

I think we can close this out. This seems to be happening because I'm using the axios module for http requests. But exactly why I have no clue. I did it the brute force way by removing parts of the code and rebuilding until the warning went away. I figured it must be part of my own code since example projects all work fine.

Any recommendations of http modules to use? Or simply just use fetch and be done with it?

[ralphtheninja]

probably axios has process within its library too this created the issue.

@Papierschiff Indeed it does:

lms@x260 ~/src/axios/axios/lib (master)
$ gg process
adapters/http.js-101-      var proxyEnv = protocol.slice(0, -1) + '_proxy';
adapters/http.js:102:      var proxyUrl = process.env[proxyEnv] || process.env[proxyEnv.toUpperCase()];
adapters/http.js-103-      if (proxyUrl) {
adapters/http.js-104-        var parsedProxyUrl = url.parse(proxyUrl);
adapters/http.js:105:        var noProxyEnv = process.env.no_proxy || process.env.NO_PROXY;
adapters/http.js-106-        var shouldProxy = true;
--
adapters/http.js-195-        case 'deflate':
adapters/http.js:196:        // add the unzipper to the body stream processing pipeline
adapters/http.js-197-          stream = stream.pipe(zlib.createUnzip());
--
defaults.js-20-    adapter = require('./adapters/xhr');
defaults.js:21:  } else if (typeof process !== 'undefined' && Object.prototype.toString.call(process) === '[object process]') {
defaults.js-22-    // For node use HTTP adapter
--
helpers/normalizeHeaderName.js-5-module.exports = function normalizeHeaderName(headers, normalizedName) {
helpers/normalizeHeaderName.js:6:  utils.forEach(headers, function processHeader(value, name) {
helpers/normalizeHeaderName.js-7-    if (name !== normalizedName && name.toUpperCase() === normalizedName.toUpperCase()) {

[FredKSchott]

Thanks for helping to debug, you're right this is a really strange one. Also really well timed: #1044 was just merged which is directly related (returns our original process.env.XXX find-replacing, which Rollup is much better at tree-shaking). My guess is that without that PR, Snowpack's internal Rollup installer wasn't able to eliminate dead code inside process.env if blocks.

I could reproduce everything mentioned above before merging, and after merging I can no longer reproduce. Can you all confirm the same?

[ralphtheninja]

Can you all confirm the same?

Yep works well now! I've also tested on my own project and same positive result.

[ralphtheninja]

Also really well timed: #1044 was just merged which is directly related (returns our original process.env.XXX find-replacing, which Rollup is much better at tree-shaking).

I had a feeling it was related, but I know too little about the project to know for sure :)

[FredKSchott]

woo!

[ralphtheninja]

Fixed by #1044