Export package as ESM

[blakeembrey]

Exporting package as ESM, I think the general shape is stable and ready to be used in next majors of type-is and negotiator.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (67e5477) to head (394c3f4).

Additional details and impacted files

@@            Coverage Diff            @@
##            master       #74   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            1         1           
  Lines          132        95   -37     
  Branches        44        20   -24     
=========================================
- Hits           132        95   -37     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[blakeembrey]

Previously done for content-disposition: jshttp/content-disposition#141. Following the same pattern, new major would target express 6 while the current version was purely for the perf boost in existing express 5 line.

[daiyam]

ESM is supported by node-v18 and node-v20. Why are you dropping them?

[gameroman]

ESM is supported by node-v18 and node-v20. Why are you dropping them?

Node.js v18 and v20 are EOL

[daiyam]

ESM is supported by node-v18 and node-v20. Why are you dropping them?

Node.js v18 and v20 are EOL

I know, but v20 isn't even 3 years old...
Dropping the support of those versions isn't a requirement for the change.

[blakeembrey]

Because node < 22 is EOL and I could be maintaining this major for the next decade, which means preparing in advance by bumping the minimum in a major release. If you're constrained by node version, use the previous major which was designed for express 5, there's no requirement to upgrade.

[blakeembrey]

Node 20 is 3.5 years old: https://nodejs.org/en/blog/release/v20.0.0

It's a breaking change to bump from node 20 -> 22, but not from node 22 -> 20, so if it's extremely important using the higher bound gives me the flexibility to do that within the current major. Let me know if there's a reason I need to reduce the major, it shouldn't be a big deal, but it's good to know why because I'd prefer to keep it at 22 for maintenance purposes.

[daiyam]

Node 20 is 3.5 years old: https://nodejs.org/en/blog/release/v20.0.0

You are right. Thought it was out in October... But still not so old.

I understand the reason to drop 20 since it's in EOL. But that decision should done as a final project requirement, not from a library or a dev tool. They should have the most compatibility and update to a version only if there a concrete technical reason to do so.

I'm coming from @octokit/request which have upgraded to content-type@3.0.0. (I did alerted them it was breaking their compatibility ("node": ">=20")).

I do understand the maintenance cost to keep 20 or 18 since lot of tools or libs have already done it. But, next year in May, it will be the same issue with Node 22 becoming EOL.