Clarifying status of webpack-contrib/webpack-serve
bebraw opened this issue · comments
Project changes proposal
Title of the existing project?
webpack-contrib/webpack-serve
Describe your proposed changes?
Make it clear for the users that the work continues at shellscape/webpack-serve. I imagine the contrib repo could become private unless there's a better way.
Why are you proposing these changes?
Now the status of webpack-serve is unclear to the users. It's actively developed and recently gained a major bump in terms of functionality as webpack-plugin-serve was integrated to it.
Any other comment?
I know there may be some politics/hard feelings behind the current situation. That said, it would be better for the user base overall too find a good solution for this so it's clear that the development is going on in another place even if unofficially.
I'm in favor for keeping it. Should we replace it with webpack-dev-server at cli or keep dev server? Dev server works fine as per now for cli
@evenstensberg The core issue is that webpack-contrib/webpack-serve has DEPRECATED notice in it and the readme explains that the package has been deprecated.
What happened last year is that a couple of developers dropped out of the project (longer story) and began to maintain webpack-plugin-serve as a third-party solution out of webpack-contrib. Then webpack-serve was simplified and ported to use this new plugin.
The current developers would be happy to maintain webpack-serve independently. This issue is more about resolving the issue on webpack-contrib side as what's stated there is misleading to the users.
This would mean webpack-dev-server can still be developed as the official option while webpack-serve would remain as a third-party option.
I'm for supporting both at webpack-cli
Doesn't supported, please use webpack-dev-server
(@bebraw asked me to weigh in) I have no opinion on the matter. However, I think it's commendable that @evenstensberg wants to support both in webpack-cli. I'd encourage you to do what you feel is best for the users, any way that goes.
I don't understand the false narrative still being used: webpack-plugin-serve is actively supported, by several diverse developers outside of the webpack organization, as is webpack-serve acting as its CLI. And we've got a happy little community of users that are enjoying the plugin and interacting with the maintainers in a positive way to improve it. We're about to see some big players adopt the plugin as well - we've been working with some large projects on transitioning from webpack-dev-server to webpack-plugin-serve.
It's about the users, and you all owe it to them to objectively evaluate the best course for them. If that course does or does not include supporting a third party alternative, the user-base will trust in your decision. And from there, we'll all keep doing our thing.