Support multiple html-webpack-plugin instances
I wrote most of the html-webpack-plugin code and would ask you to adapt your plugin a little bit.
Instead of string search and replace you might want to alter the assets array: https://github.com/jantimon/resource-hints-webpack-plugin/blob/master/index.js#L87-L89
Instead of using the options of your plugin you might want to extend the html-webpack-plugin options so it can be used in multiple instances: https://github.com/jantimon/resource-hints-webpack-plugin/blob/master/index.js#L64
Thanks for the valuable input, @jantimon. Still getting with hang of what are idiomatic best practices for Webpack plugins :)
https://github.com/jantimon/resource-hints-webpack-plugin/blob/master/index.js#L87-L89 feels a lot cleaner than the approach we're currently using here. I'm in favor of switching to it.
https://github.com/jantimon/resource-hints-webpack-plugin/blob/master/index.js#L55 appears to be where you're merging html-webpack-plugin's options with custom ones. I see no reason not to switch over to doing something similar there. I hadn't considered the multiple instance usecase but appreciate the tips!
@addyosmani cool 👍 for the html-webpack-plugin 3 version there will be an api to create custom tag elements:
https://github.com/jantimon/html-webpack-plugin/blob/version-3.x/lib/html-tags.js#L28
Maybe we will also backport it to the 2.x branch
I am always happy for feedback from plugin authors on the events and options - so if something feels to complicated please let me know
@addyosmani We can actually keep the current API as the default options for every hmtl-webpack-plugin instance, and each instance can override them if required. One thing to consider moving options into html-webpack-plugin is naming conflicts with other plugins.
@bekos
We can actually keep the current API as the default options for every hmtl-webpack-plugin instance, and each instance can override them if required.
That sounds pretty reasonable to me as well.
cool 👍 for the html-webpack-plugin 3 version there will be an api to create custom tag elements:
@jantimon Oh that's totally rad. Thanks for sharing that insight. I'd be interested in it being backported, but don't want to add too much to your workload - is V3's api surface vastly different?
The tag structure is compatible with the current html-webpack-plugin version. The main idea behind 3.x is to get closer to the webpack 2.x internals and that causes some breaking changes but we try to introduce as few api changes as possible. Your plugin shouldn't be affected at all.