Webpack 3.5.5 debugging in chrome developer tools shows two source files. One under webpack:// and other under webpack-internal://

Question

Migrated existing webpack project to use webpack 3.5.5 and its new config. Using express server instead of webpack-dev-server. I had to setup the resolve in webpack as below.

const resolve = {
    extensions : ['.js'],
    modules : [
        'node_modules',
        'src',
        'testApplication'
    ]
};

When i debug this webpack application using chrome developer tools I can see the 2 versions of source files.

1. The first one under webpack:// It is exactly matching with the source
2. The second one under webpack-internal:// This one is the babel compiled version of the source.

My questions are

1. Is there someway where I get only a first version of the file instead of both?
2. I thought node_modules should have been implicitly defined as a module rather than me specifying it explicitly in resolve, is there someway that I can make the build work without having the node_modules defined in resolve.
3. After using the same source code with webpack 3.5.5(migrated it from webpack 1.14.0) the express server start seems to have slowed node. My guess is that having specified the node_modules in modules under resolve has caused it. Any ideas?

Answer 1

1. You can configure the source maps using Webpack's devtool property. What you want is devtool: 'source-map'(source). This will only show you the original source code under webpack://. Note that there are other options that might be more appropriate for your use case.

2. ["node_modules"] is in the default value for resolve.modules. However, if you specify resolve.modules you need to include "node_modules" in the array. (source). It seems strange that you specify "src" and "testApplication" in resolve.modules. If you have local source files you should require them using relative paths e.g. require("./local_module"). This should work without having src in resolve.modules

3. Specifying node_modules in resolve.modules is not responsible for any slow down (see 2.). There are many possible reasons the slow down. E.g. maybe you are erroneously applying babel to the whole node_modules folder?