Replacing express with forked version

[joeyguerra]

I forked ExpressJS and started making the same types of changes to it as I did with Hubot; reduce dependencies, replace mocha with Node's Test Runner, use .mjs file extension, ES6 imports, async/await style.

I'd like to replace the express module in Hubot with this forked version. What are ya'lls thoughts?

[xurizaemon]

Some quick thoughts!

I'd suggest to record the why of such a proposal. I see from your description what you're planning to change but that doesn't tell why.

This should tell us what the payoff for this investment is. The investment is the effort of maintaining a fork of a long established framework, and the dependency changes it introduces. (If Hubot depends on this fork, how will Hubot's dependency on @joeyguerra personally shift?)

I'm looking for something like our #1541, where we did our best to avoid forking Hubot and eventually avoided that outcome. The closest I see is expressjs/express#5205 where it looks like there's hope of progress.

At a glance those look like big changes, but it's best for the community if we can upstream over forking by default (my opinion).

I also don't understand why Hubot should need (or benefit from) Express running tests using tool X or Y; that feels like it might arise from blurring the boundary between two components. Being explicit about reasons helps use to identify things like that.

The effort to fork is trivial but the effort to maintain a fork is significant (I realize you know this Joey!), and for both Hubot community and yourself I think it's worth careful and explicit decision.

[joeyguerra]

My general sense is that development on Express has stalled, just like Hubot did. I've also noticed when looking at other GitHub repos for other node codebases, the last commits are in years. And in general, node codebases seem to have a large number of dependencies by way of transient dependencies. My thoughts on that issue is that the more dependencies a codebase has, the larger surface area for security vulnerabilities. This, coupled with low attention from maintainers and low genuine usage exposes the codebase depending on these other codebases more and more vulnerable over time.

I'd like to have more control over the dependency sprawl in Hubot. So it made sense to me to take on a fork of Express. More specifically, the web service functionality of Hubot. I can whittle down the number of dependencies, update the codebase to modern javascript, update the minimum supported Node version, use newer features, etc.

That said, I haven't tried to help with the Express codebase. So I think I'll chime in over there to see if I can assist the maintainers to get it to a modern state with less dependencies.

[technicalpickles]

Agree with @xurizaemon's sentiment. It'd be worth at least exploring other options out there before / in tandem with exploring forking. Quick search led me to Forget Express.js — opt for these alternatives instead - LogRocket Blog. Brief summary:

• https://www.fastify.io/
• https://koajs.com/#introduction
• https://hapi.dev/

I'd like to have more control over the dependency sprawl in Hubot.

Worth asking what the motivation for this is. Like, is the issue that express has old dependencies in part not to being maintained? Or is it because there's a lot of them?

Not sure if any of these directly address the number of dependencies though.