You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With webpack 5 having recently been released, I've been interested in making some changes to this lib to make it useful to more developers. Here's a list of changes I've been thinking about that would mark a v2 phase for this plugin - in no particular order:
Remove the csp option from the plugin. Nobody uses it in any public code (through reverse dependencies on Github) and unlikely to be used in private code due it being borderline useless. To actually work in the current state another CSP plugin would need to be used for the non-runtime chunks and at that point it should just cover the inlined ones anyways.
More documentation on what this plugin does, why it does it, and how. Should still be simple to consume as a novice webpack user.
Documentation and examples covering a few cases. One a bare minimum of a skeleton webpack project with this plugin, and more complete ones with more html-webpack-plugin plugins to show a more advanced and configurable use-case in the ecosystem. Not only will it show how well it may integrate with the ecosystem (or not well), but can help improve other documentation and edge cases this package may have with other plugins.
A test suite for a variety of cases. Ideally one integration test for each valid configuration of webpack and this plugin, along with expected failure/error cases.
If the documentation expands to cover some common html-webpack-plugin setups, then the tests should also reflect these too.
Boiled down to a checklist:
Remove csp option
Support both webpack v4 and v5
Document the what/how/why of the plugin
Document use-cases with other common html-webpack-plugin plugins.
I haven't decided any testing tools or what plugins to show examples of. Maybe I'll end up researching and decided by next weekend, when I plan to start working on v2. This issue is more of a scratchpad for my thoughts, but feel free to comment any suggestions/thoughts
The text was updated successfully, but these errors were encountered:
Dual support may still be possible if html-webpack-plugin keeps a similar api between v4 and v5 (of itself, not webpack), and we keep track of the smaller differences in webpack v4-v5
With webpack 5 having recently been released, I've been interested in making some changes to this lib to make it useful to more developers. Here's a list of changes I've been thinking about that would mark a
v2
phase for this plugin - in no particular order:csp
option from the plugin. Nobody uses it in any public code (through reverse dependencies on Github) and unlikely to be used in private code due it being borderline useless. To actually work in the current state another CSP plugin would need to be used for the non-runtime chunks and at that point it should just cover the inlined ones anyways.html-webpack-plugin
already added support in a non-breaking way in some of the recent minor releases. (see added v5 compilation support and deleted depreciation warnings jantimon/html-webpack-plugin#1454 and jantimon/html-webpack-plugin@f3ccdd5)html-webpack-plugin
plugins to show a more advanced and configurable use-case in the ecosystem. Not only will it show how well it may integrate with the ecosystem (or not well), but can help improve other documentation and edge cases this package may have with other plugins.html-webpack-plugin
setups, then the tests should also reflect these too.Boiled down to a checklist:
csp
optionhtml-webpack-plugin
plugins.I haven't decided any testing tools or what plugins to show examples of. Maybe I'll end up researching and decided by next weekend, when I plan to start working on
v2
. This issue is more of a scratchpad for my thoughts, but feel free to comment any suggestions/thoughtsThe text was updated successfully, but these errors were encountered: