Store hooks as property of compilation

[GeorgeTaveras1231]

This allows reading the hooks more reliably.

Using a WeakMap in a closure causes issues if multiple versions of html-webpack-plugin are installed because it requires that plugins that tap into these hooks use the version of this package that is resolved by the webpack config. This may be a common issue in monorepos. Using a global symbol allows any version of html-webpack-plugin to resolve the hooks used in the compilation, allows plugins in monorepos to work more seamlessly.

Current workaround

I work in a monorepo where I've implemented a couple of plugins that tap in the html-webpack-plugin hooks. To bypass the issues I'm encountering, I defer the loading of html-webpack-plugin to the execution of the plugin, and use the context of the compilation to require to appropriate instance of html-webpack-plugin

- import HtmlWebpackPlugin from 'html-webpack-plugin';
+ import { createRequire } from 'node:module';
+ import path from 'node:path';

class MyHTMLPlugin {
  apply(compiler) {
    compiler.hooks.compilation.tap('MyHTMLPlugin', (compilation) => {
+    const require = createRequire(path.resolve(compiler.options.context, 'webpack.config.js');
+    const HtmlWebpackPlugin = require('html-webpack-plugin');
      const hooks = HtmlWebpackPlugin.getCompilationHooks(compilation);
      hooks.beforeEmit.tap('MyHTMLPlugin', () => { /* Omitted */ });
    });
  }
}

[jantimon]

I don't think that the html-webpack-plugin should alter the webpack compilation object

What about passing the html-webpack-plugin to the custom plugin?

class MyHTMLPlugin {
  constructor(plugin) {
    this.plugin = plugin
  }
}

[GeorgeTaveras1231]

@jantimon What is the concern with altering the object? I think this is a completely appropriate use of symbols and I imagine it's unlikely that Webpack will begin to freeze the compilation object (via Object.freeze).

I think requiring that the plugin instance be passed by reference is not ideal because it will make the plugin API much more verbose and move away from the existing API for implementing plugins for the html-webpack-plugin.

Another alternative that I would not oppose is to use a WeakMap but store the reference to the WeakMap globally (and obscure it via a global symbol) - making sure to only initialize the WeakMap once.

const weakMapSymbol = Symbol.for('html-webpack-plugin/hooks');
globalThis[weakMapSymbol] ??= new WeakMap();

// store in var for convenient access
const hooksMap = globalThis[weakMapSymbol];

Yet another alternative - since the compilation.hooks object is a POJO where the values are hook/tappable objects, maybe this feels more "ok" to alter? (I would still scope the modification with a symbol).

The other thing to consider is that it's a bit unusual that the html-webpack-plugin exposes its own tappable hooks and uses the compilation object as the central integration point. This makes sense I suppose if the goal is to allow authoring plugins that tap into both the the underlying webpack compilation object as well as the html-webpack-plugin hooks. An alternative approach to designing the plugin APIs would be to have the HTMLWebpaclPlugin constructor accept child plugins that tap into its hooks. But supporting plugins that that act on the underlying compilation or work without the html-webpack-plugin (treating the html-webpack-plugin as a sort of "progressive enhancement") will require more thought/design - since this would be a significant API change.

Here's an example of what the API could look like using this approach:

module.exports = {
  plugins: [
    new HtmlWebpackPlugin({
        // Child plugins....
        plugins: [
           new SubResourceWebpackPlugin()
        ]
    })
  ]
}