[application] proposing webpack-hot-middleware for inclusion

[glenjamin]

Hello, I've read up on #1 to attempt to understand the goals of this org, the discussion that i can see appears to be mostly technical in nature - is there anything more philosophical around?

I'm posting here as a follow-up from https://twitter.com/glenathan/status/962386906268028928

Project overview

This project was created to scratch my own itch - I wanted to use webpack-dev-server's features (especially hot reloading) - but I didn't want to run an additional nodejs process and server if my backend was already node. In general most people I've seen use this have it wrapped in a conditional which disables it in production mode.

Current Maintainance Load

At the moment, I'm the sole maintainer of https://github.com/glenjamin/webpack-hot-middleware.

Most of the issues I get are down to people with incorrect webpack config, I generally try and do some initial triage and point out obvious issues - otherwise signposting them over to other webpack support channels.

Most pull requests are for minor feature improvements.

The codebase itself is pretty stable and hasn't had any breaking changes for a long time.

The maintainence burden is currently light enough that I don't think I'm overwhelmed - but I am conscious that this is a fairly widely used project which currently has a bus factor of 1. If we agreed to do nothing else but move the repo and expand publishing rights, I think that would be a benefit.

---

To give an idea of current usage in the webpack ecosystem, here are some stats:

Downloads so far in 2018 webpack-dev-middleware - 9.8 million webpack-hot-middleware - 2.6 million webpack-dev-server - 8.7 million

The numbers here are actually a little odd, as generally you would use one or the other of dev-server or hot-middleware with dev-middleware. But either way it appears to be a decent proportion of users. The ratios used to be a bit higher towards hot-middleware but create-react-app chose dev-server so it's usage stats are much higher now.

---

So, that ended up a big longer than I thought it would be. Any thoughts?

[shellscape]

I'm very familiar with your project, as koa-webpack was using it for quite some time before switching to webpack-hot-client. I can vouch for it being very stable.

Not really weighing in so much as conveying a curiosity; What do you see as the main benefit(s) to the org absorbing the repo, beyond expanded access?

(Or, are you just looking to hand the module and it's maintenance over to webpack-contrib? Sorry if that's redundant, it wasn't clear to me.)

[glenjamin]

Primary benefit would be reduced bus-factor I think.

Perhaps also adopting some of the bots and issue templates and whatever else is set up for triage might help auto-signpost people towards the right support channels

[shellscape]

bus-factor, auto-signpost - you sir, love your tech-buzz-phrases 😆

Makes sense, thanks for clarifying.

[shellscape]

ping @d3viant0ne

[glenjamin]

@d3viant0ne @shellscape

Now that the transfer is done, do we need to discuss what being part of webpack-contrib means in practice?

I don't appear to be a contributor on the repository anymore.

I notice the commits have all beeen re-written to be categorized, which means that the git tags no longer align with the git commit history.

Are there other changes like this planned, is this the best place to discuss them?

[joshwiens]

Check your email :)

[glenjamin]

Bus factor successfully reduced, thanks! :)