Supporting require.resolve dynamic passing

[vercel]

Supporting require.resolve dynamic passing

[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.

[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.