Webpack 2.0 checking existence of tree shaken ES6 module imports - ecmascript-6

Question

In Webpack 2.0 (#2.1.0-beta6), if I go to import a file that points to a file that doesn't exist, I get a build time error.
//x.js
import { foo } from './y'
//y.js
export function foo () { return 5 }
If I go to import an export that doesn't exist from a file that exists, I get a runtime error.
//x.js
import { baz } from './y'
//y.js
export function foo () { return 5 }
Is there a way to have Webpack check exports in the same way it resolves files?
//webpack.config.js
module.exports = {
module: {
loaders: [
{
test: /\.js$/,
exclude: /node_modules/,
loader: 'babel-loader',
query: {
presets: ['es2015-native-modules']
}
],
}
}

Answer 1

I believe a runtime error in this case is correct behavior. You probably aren't getting a runtime error from the import itself, but only when you try and use it it is undefined.
A file existing or not can be easily determined by a system call during build time. However, a module exporting a given value or not can be changed at runtime - not that that is a good idea - so Webpack doesn't make a build time decision as to whether or not it should bail out.
Consider the following code:
// hats.js
var hats = undefined;
if (Math.random() > 0.5) {
hats = 'i have a hat!';
}
export const HATS = hats;
// index.js
import { HATS } from './hats';
console.log('hats is:', HATS}
Webpack can't know at build time whether or not HATS is going to exist at run time, so it won't error out when I try and import hats. However, HATS will correctly be either undefined or 'i have a hat!' when logged during execution. Similarly, if i remove the export line from hats.js, it will simply always report undefined, because Webpack cannot tell the difference after transpilation - HATS is simply undefined still. If I remove hats.js completely, Webpack knows something is definitely wrong and errors out.

Answer 2

As of webpack#2.1-beta15, warnings have now been added for imports of ES6 exports.