html-webpack-plugin should be a peer dependency, or not directly require()'d

As it happens; webpack-subresource-integrity makes a require('html-webpack-plugin') call, but doesn’t list it anywhere in its dependencies (not even as a peer dependency).

While it works on most installs at the moment, it’s only by accident, and package managers offer no guarantee that this will hold true much longer; in fact, it breaks now with Plug’n’Play and likely with pnpm as well.

Adding webpack-subresource-integrity as a peer dependency would have the unfortunate side effect that users would get a warning, but that’s a separate (non-blocking, I hope, since it’s purely visual) problem that should be solved on the package managers side 🙂

[arcanis]

No, PnP doesn’t make static analysis on the code itself, only on the dependencies reported in the package.json files. Our goal isn’t to automatically install things you require, but rather to leverage the Yarn cache to fulfill all projects on the machine at once (instead of copying them around).

So the error thrown is at runtime - we inject a hook in the environment that replaces part of the Node resolution (the one that locates the “right” node_modules directory) by a resolution based on static resolution tables generated by yarn install. When this resolver sees a require that’s not part of the tables (because Yarn wasn’t aware of the connection), it throws. This ensures that packages can only access their direct dependencies rather than relying on the hoisting (hence solving cases of “works on my computer”).

[edmorley]

I’ll think more about it, but the main issue is to find an API that would work regardless of the package manager

I’ve filed yarnpkg/yarn#6487 to continue exploring this, since I can think of several projects where the same issue will come up.