Within the use cases around custom loaders (think Babel plugins, webpack loaders), there are a number of edge cases of dynamic require that come up. While Webpack can get quite far in computing dynamic requires like require(require.resolve('./asdf.js')), there is a tricky case where there is a separation between the resolution and the require:

// example use case something like "plugin: require.resolve('./asdf')" being passed as an argument
const req = require.resolve('./asdf.js');
require(eval('"' + req + '"')); // or any other untracable logic before passing to require

In this case, what Webpack does is replace the require.resolve part with the ID of the module in the webpack bundle, so we get something like:

const req = 234;
__webpack_require__(123)(eval('"' + req + '"'))()

Where 123 is effectively an inlined "throwing" module which will give the error "Module 234 not found".

The above then fails as a module not found, all of the time.

The naive fix I was thinking to implement would to instrument the "throwing module" (123 in the example) to first check the webpack_require cache for the numeric ID.