RFC: Reduced support for webpack

When we started with open-wc, using rollup for web apps was still pretty new. We started out with configs and recommendations for both webpack and rollup, and were mostly neutral in our recommendations between the two.

Over time the story for using rollup for web apps improved a lot and we starting leaning more and more towards Rollup. We now generally recommending it for all use cases.

As a project open-wc has grown a lot, we picked up a lot of tools, guides and configurations over time. All these things cost time to maintain. We have to be careful we don’t grow too big, and sometimes let go of things that no longer fit with the goal of open-wc or things that didn’t work out so well.

Whenever we add new things for rollup, our current policy is to also add an equivalent for webpack. I’d like to change that strategy, going more all-in on rollup and reducing the level of support we have for webpack.

I don’t want to forget about webpack users, a lot of people don’t have the freedom to choose their tools and we still should provide guidance and building web components for them. But these same people likely cannot use our plugins or configs, but need to integrate in an existing build setup. Our documentation and recommendations should focus on that, and it’s actually an area we are lacking in already.

In practice, I’m proposing the following changes:

• Deprecate webpack-index-html-plugin
• Remove the multi-build option from building-webpack (which was always a hack anyway)
• Use webpack-plugin-html in building-webpack (losing the ability to use HTML as input)
• Add docs on web component specific requirements when integrating with an existing webpack config
• Remove webpack option from generator
• Make rollup more prominent in our docs

This is not something we will do overnight, I’d like to gather feedback (from other maintainers & the community) on this approach first.

[LarsDenBakker]

I dont agree, I have used both extensively and I find rollup a lot simpler to understand and use.

We recommend building web components with es modules, and to load polyfills as scripts.

[emilio-martinez]

I kind of tend to agree with a full webpack config may not be worth the maintenance. To be honest, it’s great from a “getting started” point of view, but depending on the requirements of various projects, I’ve ended up just using it as reference due to the need to heavily customize the webpack config anyway, or having to integrate it into an existing webpack pipeline.

Would it make sense to just convert the package into a set of utilities/plugins for people to piece together their own config? For example, the particulars of the babel config would become a babel preset? After all, some parts are already their own open-wc packages now.