chore: bring in the changes from fastify/send

[bjohansebas]

Hi! I’m bringing in the changes from fastify/send so we can work on a version that doesn’t break the current send API too much, while still getting the performance improvements from the send fork. The goal is only to bring in the existing changes for now, not to make it compatible yet. I’ve noticed that they removed some dependencies and added their own implementations of those dependencies in their fork; I think we could send those changes upstream so everyone can benefit from them. While it’s probably possible to work on an API in Node core, we also need to focus on our current issues.

base commit: fastify/send@030392f of fastify/send

closes #159

cc: @mcollina @Uzlopak @Fdawgs @climba03003 because they are the ones who maintained the fork.
cc: @pillarjs/express-tc

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	fast-decode-uri-component@​1.0.1
	benchmark@​2.1.4
	@​lukeed/​ms@​2.0.2
	mime@​3.0.0
	c8@​10.1.3
	tsd@​0.33.0
	neostandard@​0.12.2
	eslint@​7.32.0 ⏵ 9.39.2	-2		+1	+44
	@​types/​node@​25.0.10

View full report

[blakeembrey]

There's a few changes in the test suite from t. to using node:assert that I think we can omit from the PR and follow up on, but LGTM as a starting point to iterate from if the Fastify team is good with this.

[blakeembrey]

Consistent contributors list.

[bjohansebas]

What do you want me to do, remove them or what?

[blakeembrey]

They can all be written in the same format, no need to remove any. I can also do it in a follow up PR if you prefer.

[bjohansebas]

Let’s do it in follow-up PRs

[blakeembrey]

I wouldn't change the license so much but we can add:

Suggested change

	Copyright (c) 2023-present The Fastify team
	Copyright (c) 2023-2025 Fastify Team (https://github.com/fastify/fastify#team)

[bjohansebas]

I'm not sure if that is allowed.

https://github.com/openjs-foundation/cross-project-council/blob/main/governance/IP_POLICY_GUIDANCE.md#editing-existing-copyright-notices

[ctcpip]

per the guidance:

By using this format, the project avoids having to deal with names of copyright holders, years or ranges of years, and variations on the (c) symbol.

I think the changes needs to be:

Copyright The Fastify Contributors.
Copyright The Express Contributors.

and avoid any other changes

[bjohansebas]

done

[bjohansebas]

There's a few changes in the test suite from t. to using node:assert

Yes, but that was done to maintain compatibility with Node.js 18, since t.assert was added in later versions.

[bjohansebas]

Next changes would be to go back to using mime-types, go back to using range-parser, also use etag as a dependency, things like that which were removed because of the fork.

[blakeembrey]

Yes, but that was done to maintain compatibility with Node.js 18

Is node 18 a requirement? I didn’t see that mentioned, I thought I this PR was a direct port and we’d do follow up PRs for changes.

[bjohansebas]

Is node 18 a requirement? I didn’t see that mentioned, I thought I this PR was a direct port and we’d do follow up PRs for changes.

Well, that’s what the latest change does. If you want, I can do restoring that support in a follow-up PR and have this one only bring in the Fastify changes.

Edit: I’ve already removed those changes, and now it only supports Node>= 20 because of the test runner features. In follow-up PRs, we can bring back support for Node.js 18, 19 and 21.

[blakeembrey]

Well, that’s what the latest change does. If you want, I can do restoring that support in a follow-up PR and have this one only bring in the Fastify changes.

I wanted to understand if it’s a requirement that I’ve missed somewhere, otherwise I’d push for a new major being v22 onwards. Everything else will be unmaintained by the time this releases as a major.

[bjohansebas]

I wanted to understand if it’s a requirement that I’ve missed somewhere, otherwise I’d push for a new major being v22 onwards. Everything else will be unmaintained by the time this releases as a major.

What our LTS policy says is a bit vague, and I don’t think the topic has been discussed further or has it? (i don’t remember), but the understanding (and how it has been handled so far), is that the support we have in Express is the minimum we must maintain in dependencies/middlewares. This would indicate that we should support the same minimum Node version that Express supports. https://github.com/expressjs/discussions/blob/master/docs/adr/352-lts-strategy.md#decision

express dependency packages will follow the same timeline and support dates for the express version which they are included with.

So far, this will be included in Express 5, since Express 6 has not been defined yet

[blakeembrey]

is that the support we have in Express is the minimum we must maintain in dependencies/middlewares

That is an LTS document for Express, not node.js support, and IIRC in calls I advocated for and it was agreed that the dependency would be maintained as long as depended on in Express, and there was no requirement for new majors to support current express versions. Using a new major in the current Express version is a whole different can of worms, and independent to this PR which is meant to be porting work from a fork.

My priority is:

1. Merging the fork and removing duplication so the whole ecosystem is safer (one dependency, one CVE triage).
2. Making sure it can be maintained long term, as that's what I'm signing up for
3. Making sure any new major can be used in the existing version of Express

FWIW, if every release had to work in the current major of Express it would be impossible to bump node version support. As such, this PR should only be to port the work and patch minor things (e.g. README, package name) and follow up PRs to figure out the level of support required for old node versions or API changes can be done later.

In the original PR description:

The goal is only to bring in the existing changes for now, not to make it compatible yet.

This is what the PR should be. I'd leave everything else to future PRs. The most important thing is obtaining ecosystem buy-in from Fastify, then iterating to a place where it's in the best place for as many users as possible (including Fastify, Express, etc). If needed the existing major can be used indefinitely, which isn't unprecedented. I maintained path-to-regexp 0.1.x for 10 years before Express moved to the current major. I prefer that over being unable to change anything for 10 years, so we should do the best we can for the package today and worry the rest later. And who knows, perhaps node 18 support will be naturally anyway because there aren't any trade-offs.

[blakeembrey]

cc @mcollina @Fdawgs @Uzlopak

I'm happy if y'all are, I'll iterate and release this similar to cookie. I'd like to look into further perf optimizations and any potential breaking changes from this PR I can cc @Fdawgs. I don't anticipate breaking things for fun or backward compatibility, only if there's a major performance or maintenance win hidden somewhere that requires it.