Supporting require.resolve dynamic passing

[guybedford]

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.

[TooTallNate]

This is a webpack-specific hack that works TooTallNate/node-bindings@40dcc1f

[guybedford]

Nice, that seems a sensible approach to getting bindings working. Although it relies on the node_modules location right?

[TooTallNate]

It's just a way to "break out" from the webpack "fails as a module not found, all the time" scenario and get access to the native require. Indeed this is a runtime thing though so maybe it's not applicable here.

[guybedford]

@TooTallNate another option for breaking out of webpack without per-package hacks might be to reinstrument https://github.com/webpack/webpack/blob/master/lib/ContextModule.js#L610 through the plugin system (I'm sure there's a way!) to check the global require on not found first.

[guybedford]

I tried hacking the above approach to make webpack loaders work, but unfortunately passing string ids through the resolver was causing breaks in the internal loader logic (eg loader resolve -> "1026" kind of thing).

That was the primary goal of this issue, although the approach may still work for Babel plugins.

Leaving this one for now.

[guybedford]

Reopening this issue, as coming up with a solution to these dynamic cases will solve #141, #148, #290.

[guybedford]

In #378 this is resolved by two mechanisms: (1) require.resolve is statically analyzed so in the above example, the require itself is known, and (2) require.resolve when not possible to statically determine is replaced with the resolve of the target environment.

The result is that the edge cases left of require.resolve are exactly the edge case of dynamic require support. So we can track further in its own issue on that.