stringifyRequest - wrong relative path

[jantimon]

Source:
a failed unit test of the html-webpack-plugin webpack 4 branch

Error:
Module not found: Error: Can't resolve '../../home/travis/build/jantimon/html-webpack-plugin/node_modules/lodash/lodash.js' in '/home/travis/build/jantimon/html-webpack-plugin/spec/fixtures':

Description:
stringifyRequest does always transform an absolute path to a relative one based on the loader context. Unfortunately the loader context is sometimes different from the compiler context.

loader-utils/lib/stringifyRequest.js

Line 24 in 67499ff

singlePath = path.relative(context, singlePath);

Loader Context:

The reason for the loader context not to be the same as the compiler context is a resolve plugin which manipulates the context to resolve a modules dependencies properly:

    compiler.hooks.normalModuleFactory.tap(
      "ChangeModuleResolution",
      nmf => {
        nmf.hooks.beforeResolve.tapAsync(
          "ChangeModuleResolution",
          (data, callback) => {
            if(someCondition) {
               data.context = '/a/path/';
            }
            return callback(null, this._resolveDependency(data));
          }
        );
      }
    );

Loader Code:

console.log({
    loaderContext: this.context,
    compilerContext: this._compiler.context,
    resolve: require.resolve('lodash'),
    loaderUtils: loaderUtils.stringifyRequest(this, '!!' + require.resolve('lodash'))
  });

{ cwd: '/home/travis/build/jantimon/html-webpack-plugin',
  loaderContext: '/tmp/tmp-1529996640938-WMgSVD1rkurD',
  compilerContext: '/home/travis/build/jantimon/html-webpack-plugin/spec',
  resolve:
   '/home/travis/build/jantimon/html-webpack-plugin/node_modules/lodash/lodash.js',
  loaderUtils:
   '"!!../../home/travis/build/jantimon/html-webpack-plugin/node_modules/lodash/lodash.js"' }

Result from: https://travis-ci.org/jantimon/html-webpack-plugin/jobs/396738867

errorDetails:

{ id: './lib/loader.js!../../../../../tmp/tmp-1530024669301-m1fuknBuohSp/plain.html',
            identifier: '/home/travis/build/jantimon/html-webpack-plugin/lib/loader.js!/tmp/tmp-1530024669301-m1fuknBuohSp/plain.html',
            name: './lib/loader.js!/tmp/tmp-1530024669301-m1fuknBuohSp/plain.html',
            ....
            source: 'var _ = require("!!../../home/travis/build/jantimon/html-webpack-plugin/node_modules/lodash/lodash.js");module.exports = function (templateParams) { ...}}' } ],

Full log and trace is here: https://travis-ci.org/jantimon/html-webpack-plugin/jobs/396925410

[jantimon]

I managed to reproduce the root of the issue.

Demo as Zip: webpack-context.zip

Click to expand Demo Code

loader.js

module.exports = function myLoader(source) {
  console.log('loader', {
    requrest: this.request,
    context: this.context
  }); 
  return source;
}

index.js (Webpack compiler)

const webpack = require('webpack');

class CustomResolvePlugin {
  apply(compiler) {
    compiler.hooks.normalModuleFactory.tap(
      "CustomResolver",
      nmf => {
        nmf.hooks.beforeResolve.tapAsync(
          "CustomResolver",
          (data, callback) => {
            // Change context from 'src/a/' to src/b/
            // to allow 'a.js' to require './b.js'
            if (data.context.indexOf('/a') !== -1) {
              data.context = __dirname + '/src/b';
            }
            console.log('plugin', {
              requrest: data.request,
              context: data.context
            })
            return callback(null, data);
          }
        );
      }
    );
  }
}

webpack({
  mode: 'development',

  module: {
    rules: [
      {
        test: /a.js$/,
        loader: require.resolve('./loader.js')
      }
    ]
  },

  plugins: [
    new CustomResolvePlugin()
  ]
}).run(((err, stats) => {
  console.log('errors', stats.compilation.errors)
}));

src/index.js (entry point)

require('./a/a.js');

src/a/a.js (the target where the context is changed)

require('./b'); // <-- will work only because of the resolver plugin

src/b/b.js (the dependency of a.js)

console.log('hello world from - b');

Output:

1) plugin { request: './src',
  context: '/webpack-demo' }

2) plugin { request: './a/a.js',
  context: '/webpack-demo/src' }

3) loader { request: '/webpack-demo/loader.js!/webpack-demo/src/a/a.js',
  context: '/webpack-demo/src/a' }

4) plugin { request: './b',
  context: '/webpack-demo/src/b' }

As you can see the context is changed by the plugin in (4)) after the loader is executed (3)).
Therefore the loader context still points to '/webpack-demo/src/a'.

However that should not be the case because the context is changed by the CustomResolverPlugin from '/webpack-demo/src/a' to '/webpack-demo/src/b'.

If we now used the loader-utils path.relative(context, singlePath); it would still use the old context to create a relative path.

[jantimon]

I also added a unit test for the webpack-recompilation-simulator which fails for that case: https://travis-ci.org/jantimon/webpack-recompilation-simulator/builds/399443099

[jantimon]

It seems like webpack requires the absolute path:

'Why is this necessary? Since webpack calculates the hash before module paths are translated into module ids, we must avoid absolute paths to ensure consistent hashes across different compilations.'

Unfortunately the loader-runner does not allow to modify the context:
https://github.com/webpack/loader-runner/blob/0d41655430a52af88e6a423c6d8df5c22d413e81/lib/LoaderRunner.js#L250-L253

So this is not possible anymore with webpack 4.

Thanks for all the hints @sokra 👍👍