💡 Support https://webpack.js.org/plugins/provide-plugin/

[tryggvigy]

Suggest an idea for this project

I wonder if we could support ProvidePlugin somehow. I see https://github.com/webpro-nl/knip/blob/1cf68c8987bca64de78d89fac5e7bd6f088ea698/packages/knip/fixtures/plugins/webpack/webpack.common.js#L89 references it but it's not listed as an issue. I found that in our project when buffer is in package.json and

    new ProvidePlugin({
      process: 'process/browser',
      Buffer: ['buffer', 'Buffer'],
    }),

is defined in a webpack config, buffer gets listed as a unused dependency

[webpro]

In the webpack plugin, is there any way to find this in localConfig or resolvedConfig? That's the resolved exported value of the webpack config file (e.g. your webpack.config.js).

[tryggvigy]

Right, good call. No, I don't think there is a way through the config value.

When I log resolvedConfig.plugins out in src/plugins/webpack/index.ts and run the webpack test I get

[ MiniCssExtractPlugin {}, ProvidePlugin {}, CopyWebpackPlugin {} ]

not sure what I'm looking at. At first I thought it was instances of these plugins, so basically an instance of https://github.com/webpack/webpack/blob/96c543c0a976e7d0a2dadd8ff0d6525f99bc3417/lib/ProvidePlugin.js#L25 but it doesn't seem to be since I can't access this.definitions and I thought to myself: "that makes sense, Knip is not actually executing the webpack config, that might have all kinds of side-effects".

So I guess the plugins are just opaque named empty objects/classes or something?

Hoping my hunch is right.

This seems hard to solve with the current plugin API interface where you get a resolved config (which is a really nice api). The plugin would need access to the AST or raw string contents of the file to parse out this ProvidePlugin dependency

[webpro]

Knip is not actually executing the webpack config

So I guess the plugins are just opaque named empty objects/classes or something?

Knip loads and executes files like webpack.config.ts, but nothing else (i.e. it does not call functions or instantiate classes). Whatever that config file exports is handed over as the first argument in resolveConfig(localConfig).

The plugin would need access to the AST

Exactly, this has been on my mind for a while (I should add this to the list: https://knip.dev/reference/faq#why-doesnt-knip-have). But so far, the need has surfaced only rarely and it would mean opening up a new API surface area I'm currently not too fond of.

[tryggvigy]

Yeah I completely agree. That type of API is bloated. Maybe there could be some sane way to solve this (or maybe not), but rushing an API for it is not a good idea.