Need your help for renaming this plugin

[webdiscus]

Hello developers,

I need your help choosing a new name for this plugin because "html-bundler-webpack-plugin" is a "very, very terrible name...", said Andrew Lisowski in the video www.youtube.com/@devtoolsfm, and I agree with him.

Please, choose a best name for the plugin or write your suggestion.

Note: this plugin can be used as CSS extractor instead of followings:

• mini-css-extract-plugin
• webpack-remove-empty-scripts
• resolve-url-loader
• svg-url-loader
• see the complete list

NOTE

This plugin must be Plugin number 1 for Webpack, because with just this one plugin you can start to building your website.

The naming rules:

1. The name should contains max 3 parts, e.g., bundler-webpack-plugin.
2. The package name must be free in the npm repository.

[webdiscus]

NOTE

Please, add your variant of a plugin name here.

[davidmurdoch]

Voted html-bundler-plugin, but I like bundler-plugin just as much as html-bundler-plugin!

[vralle]

It's not entirely clear to me what goals will be achieved by renaming the plugin. From the obvious, a certain number of users will be disoriented because they will not be able to find the usual tool called html-bundler-webpack-plugin

[webdiscus]

I don't care about popularity but the name should help identify the project.
Thanks.

[vralle]

Copilot (GPT-4)
I want to see more colorful, unique and memorable names for this plugin: https://github.com/webdiscus/html-bundler-webpack-plugin

[webdiscus]

Thanks, very funny, but I will take shortly and concrete name, like bundler-plugin, no abstract names ;-)

[webdiscus]

I don't trust IA, only real man can do it :-)

[vralle]

You are the real author of this plugin. And you want a new name for the plugin. What name can you come up with to better identify the plugin?

Maybe Copilot isn't so bad after all)

[Bessonov]

"Everything-Everywhere-All-at-Once-webpack-plugin" 🤣

Personally, I’m fine with the current name. However, what does the plugin do at its core? I voted for "bundler-webpack-plugin," as I think it describes the main purpose of the plugin well. "entry-plugin," or perhaps "entry-webpack-plugin" (since the plugin is tied to Webpack, right?), also works.

On the other hand, what is the long-term vision for the plugin? Do you plan to integrate support for every template engine into it? Or should the community create plugins for your plugin, making it more decentralized?

By the way, thank you for your amazing work!

[webdiscus]

On the other hand, what is the long-term vision for the plugin?

The plugin will be extended with new useful features.

Do you plan to integrate support for every template engine into it?

Yes. All most popular template engines are already supported. Today is added support the Markdown with highlighting code.
What template engines are still missing?

should the community create plugins for your plugin, making it more decentralized?

The plugin is extendable with custom plugins. Everybody can create own plugin using the Plugin Hooks.

[Bessonov]

What template engines are still missing?

I don't miss any. I love Pug; however, because it is very focused on HTML, it can't be easily used for LaTeX documents or SQL scripts. Because of that, and since Handlebars takes security into account, I use Handlebars more and more. I see some efforts to make ReactJS backend-friendly. Maybe this could become my favorite template engine in the future, just because I like ReactJS and already use it for SPAs.

Today is added support the Markdown with highlighting code.

I saw it in the commits, and it sounds great! The only danger I see is that supporting all of them can be very time-consuming.

So, based on your answers, I would still vote for bundler-webpack-plugin 👍

[webdiscus]

I love Pug

I love Pug template engine too. The Pug compiler is fastest.

Personally, I don't like React-like frameworks.
React is an anti pattern, therefore I promote using simple and right way with canonical template engines.

[webdiscus]

The only danger I see is that supporting all of them can be very time-consuming.

Yes, of course, that's the other side of the coin.

Why did I create HTML Bundler Plugin?

The existing html-webpack-plugin is small with limited, crooked functionality. Many third-party plugins were maked to expand its capabilities. But none of them solved the problem well. All of them were essentially crutches. And this whole zoo did not solve the main problem simply and clearly - render templates from source asset files of temlates, scripts, styles, etc.

It is also dangerous that different developers will simply stop supporting and developing its plugins/loaders, as has already happened with many plugins and loaders:

• pug-loader - last update 6 years ago
• pug-html-loader - last update 8 years ago
• html-webpack-inject-preload - last update 3 years ago
• html-webpack-inline-source-plugin last update 5 years ago
• resolve-url-loader last update 2 years ago
• webpack-subresource-integrity last update 2 years ago
• handlebars-webpack-plugin last update 4 years ago
• nunjucks-loader last update 6 years ago
• etc..

Isn't it dangerous if many functionally important parts are not working?
Now the html-webpack-plugin is a leaky trough with a bunch of old crap.

Issues

The most important thing is not even the number of contributors, but how quickly they respond and solve issues.
Look at the long issue list by other plugins . Many issues have been hanging for many years.

And look at the list of yet unresolved issues in the bundler plugin, as well as the list of already solved issues, how quickly was responded and how quickly was solved.

The HTML Bundler Plugin is modern, powerful, comprehensive. A full set of necessary functions out of the box. The plugin works logically and intuitively. Many people appreciated this, for example, Mozilla uses it.

What is better, a vendor lock from many single programmers, or from one (several) but making the tool convenient to use?

There is no single correct answer here. Everyone chooses what is most convenient for them.

P.S.

This plugin is like my child, whom I constantly develop and fix bugs for many years.

Grüß aus Köln ;-)