Full build sometimes miscompiles imports, incremental build OK

[viridia]

I've been seeing a problem for several months now (about the time I upgraded to the most recent webpack) where an import statement will yield a correct value in an incremental build, but will produce an undefined value in a full build.

Example:

import React from 'react';
import classNames from 'classnames';
import { withRouter } from 'react-router'; // 'withRouter' is undefined

What's interesting is that the bug only occurs in the initial build. If I touch any source file and refresh the page, the code works properly.

Unfortunately, I cannot produce a small example that reproduces the problem, because it only seems to affect one import out of several thousand in a large proprietary code base.

I don't expect anyone to be able to figure out the problem given the limited details I am able to offer; what I would like is advice on how to dive deeper and diagnose what's going wrong. For example, I thought if there was a way I could disable tree-shaking, or turn off module support and revert back to babel modules, that would at least eliminate one possibility. (I opened a question on SO, but no responses so far).

My babel configuration is fairly simple:

babel_plugins = [
  'transform-object-rest-spread',
  'react-hot-loader/babel',
];
babel_presets = ['react', ['env', { modules: false, targets: { browsers: 'last 2 versions' } }]];

My current version of webpack is 2.3.3 and webpack-dev-server is 2.4.2. My OS is Mac OS 10.11.6.

[viridia]

I still see this problem several times a day - I'm not asking for someone to solve it with the limited information I can provide, just some hints as to how I might go about investigating the problem.

[viridia]

ping?

[viridia]

This is still happening several times a day, even though I've upgraded both babel, webpack, react, and react-router in the months since I first encountered this bug. I've been working around this using the following technique: Whenever I start webpack, the initial build will always be wrong, however if I 'touch" any source file, it will do an incremental compilation and then everything will be OK.

I now have about 6 different webpack projects, and this issue manifests in only one of them (the largest one).

The part that's annoying for me is having to explain to the other members of my team that they have to touch a source file after starting the frontend server whenever they want to run it on their workstation.

[shellscape]

I'd recommend first and foremost updating your dependencies - they're pretty far out of date. david is a great module to help facilitate updates. I'd also check your node version just to be thorough. If that doesn't solve your issues, then we're going to need a test case app in a repo in order to be able to reproduce. This is just one that we've never really seen before. If that test case repo is created and posted here we can revisit this issue.

[viridia]

All right, after much effort I managed to carve away 99% of my application and create a minimal example that demonstrates the problem:

https://github.com/viridia/webpack-miscompile

To reproduce:

1. checkout the code
2. yarn install
3. yarn start
4. navigate to http://localhost:8000/
5. Look at the JS console. Notice that there's a JS error.
6. Touch any source file.
7. Reload the page. Notice that the error is gone!

Note: when reproducing this, you should see exactly two 'compiled successfully' messages from webpack. If you see any number other than two, hit Ctrl-C and go back to step 3.

Please look at this and re-open the bug. Thanks!

[viridia]

Also, a little more info:

The JS error that appears on the console will look something like this:

authService.js:9 Uncaught TypeError: Cannot read property 'tokenKey' of undefined
    at Object.<anonymous> (authService.js:9)
    at __webpack_require__ (bootstrap 1398035…:19)
    at Object.<anonymous> (main.js:3)
    at __webpack_require__ (bootstrap 1398035…:19)
    at Object.module.exports (vertx (ignored):2)
    at __webpack_require__ (bootstrap 1398035…:19)
    at bootstrap 1398035…:65
    at main.1398035….bundle.js:69

In the file 'authService.js' you will see this:

import { env } from '../global';

class AuthService {}
AuthService.TOKEN_KEY = env.tokenKey;

The value 'env' is undefined.

However, when after an incremental compilation the value is correctly defined.

In a large project, this particular problem will show up in different places depending on the order of imports, but the symptoms are always similar: an imported symbol set to undefined value after a full webpack-dev-server build, but correctly defined after an incremental build. Note that non-dev-server builds are not affected, that is a full webpack build always works correctly. The problem only manifests when running via webpack-dev-server.

I've determined that this is independent of hot reloading; turning hot reloading on or off, or installing the hot module plugin has no effect either way.

[shellscape]

@viridia out of curiosity, have you tried using webpack-dev-middleware independently to see if that module is the cause. (it sounds like it might be)

[viridia]

I have not, but I can give it a try. I'm not currently using Express in this project (unlike all my other webpack-based projects).

[shellscape]

@viridia ping. I don't want this one to get too stale. We're unable to find a root cause on our end for this. If you can find a cause, we'd be happy to start looking at a fix for you, and we'd always welcome a PR. this one may point back to webpack proper.

[viridia]

OK further updates:

• The problem is reproduceable using webpack-dev-middleware
• The problem goes away when I remove the callback argument to webpack, i.e.:

// Bug occurs
const compiler = webpack(config, () => {
  console.log(`Now listening on http://localhost:${PORT}`);
});

// Bug does not occur
const compiler = webpack(config);

[MichaelOstermann]

I'm currently having the same issues as @viridia and I can confirm removing the callback works, however for some strange reason regular builds don't work without a callback.

My version of webpack is 3.5.6 and webpack-dev-server is 2.7.1, running on Mac OS 10.11.5.

Let me know if there is anything specific that I can look into to help resolving this issue!

[shellscape]

@viridia @MichaelOstermann given everything listed here, my inability to reproduce locally here, and that it's reproducible with webpack-dev-middleware, I'm leaning towards this not being an issue with this module. Rather, likely webpack proper. I looked into webpack-dev-middleware and how it was using the compiler, and it's really doing nothing more than pulling path info from it. I think the next stop for you all is an issue on the webpack's main repo.

[viridia]

Gotcha. Since discovering the effect of the callback, I've been able to work around the problem by simply removing it, as it was non-essential. (My original reason for adding it was to print additional instructions for new engineers.) So my need to have this solved has greatly diminished. (And in fact, I notice that builds have also gotten considerably faster).

If I were to spend any more time on this, thie first thing I would check is what the middleware expects the return value of the callback to be.

[shellscape]

@viridia great, thanks for that follow up. should we close this issue then, in your mind?

[viridia]

Fine by me.