plugin-webpack: reference webpack loaders with require.resolve for yarn pnp compat

[mxmul]

Replaces implicit Webpack loader resolution (e.g. loader: 'babel-loader') with an explicit require.resolve call (e.g. loader: require.resolve('babel-loader')). This should be a noop for regular npm/yarn installs, but is required when using Yarn 2 PnP and pnp-webpack-plugin (because Yarn 2 overrides Node's module resolution, but not Webpack's enhanced-resolve).

Context: https://github.com/arcanis/pnp-webpack-plugin#usage

In my project, I'm using Yarn 2 and pnp-webpack-plugin like so:

    ['@snowpack/plugin-webpack', {
      extendConfig: (config) => {
        return merge(config, {
          resolve: {
            plugins: [
              PnpWebpackPlugin,
            ],
          },
          resolveLoader: {
            plugins: [
              PnpWebpackPlugin.moduleLoader(module),
            ],
          },
        });
      },
    }],

Before this patch, the build fails with Entry module not found: Error: Can't resolve 'babel-loader'. After applying my changes, it succeeds.

Changes

Loader paths are resolved with require.resolve instead of Webpack's enhanced-resolve.

Testing

Existing tests pass. A real regression test (that installs the required packages under pnp) would be complex, and doesn't seem like it would provide a ton of value.

Docs

No documentation, since this is a bug fix.

[vercel]

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/pikapkg/snowpack/e3jjdwd93
✅ Preview: https://snowpack-git-fix-webpack-pnp.pikapkg.vercel.app

[merceyz]

This should be a noop for regular npm/yarn installs, but is required when using Yarn 2 PnP

It's technically always required, otherwise the project relies on hoisting to bring the dependencies to the top level, which is not guaranteed to happen
https://yarnpkg.com/advanced/rulebook#packages-should-only-ever-require-what-they-formally-list-in-their-dependencies

[FredKSchott]

nice! makes sense. For some reason, I thought that Webpack only supported a name here, and not fully resolved paths.