Open jscheid opened 5 years ago
This failing test is related to #3, which I think is a wontfix (I should remove the test). The modules
field (just like NODE_PATH
) simply doesn't make sense w/ PnP.
Ah, good to know, thanks.
@arcanis I might be missing something, but it appears the before-module
hook is never invoked by the passing tests. I can add a throw
in there and the same tests still pass. Isn't that the core of the plugin?
The tests under their current form mostly are "it should not break feature X from webpack". Since Yarn itself is built using pnp-webpack-plugin
(and thus acts as a de-facto integration test), I didn't take the time to write extensive tests that validate that it works fine in a PnP environment (it would be a good idea, though).
Of note, the current tests don't go through the before-module
because they happen before in the resolution step. One additional test we should have is a version of "shouldn't prevent the 'extensions' option from working" that doesn't use relative paths, so that we can check that the extensions are properly resolved even when PnP is used to resolve a path.
Of note: I'm currently in the process of proposing it for being a builtin plugin, in which case it would benefit from all the existing test infra (it also mocks a small PnP API so it's a bit more extensive that the current testsuite).
Oh. In that case, it would be better to backport that PR to older enhanced-resolve branches, if only because it would allow replacing this terrible, terrible hack:
resolver._plugins.file = resolver._plugins.file.map(plugin => (
plugin.toString().indexOf('"resolved symlink to "') < 0 ? plugin : (request, callback) => callback()
));
by something much nicer like https://github.com/webpack/enhanced-resolve/pull/168/files#diff-2d048cd0f0a4be9ba200a00089d3f3edR295
I'm afraid this turns out too deep a rabbit hole for me. I'll first try working around it by avoiding this plugin altogether - by using something like { loader: require.resolve('style-loader' }
instead of "style-loader"
).
I'm curious though - what's preventing you from upgrading to more recent Webpack releases? Wouldn't that be less work?
I'm refactoring tests for a Webpack plugin (you might remember it) and I'd rather not drop compatibility with, and thus tests for, (at least) Webpack 3 just yet. I will, if this turns into a major ordeal, but I'm pretty close to a simple solution for keeping them around.
I was thinking of taking a shot at #2, but it would be nice if all tests would pass first.