v2.0.0 - Major Release (Proposal)

[Phillip9587]

I have created a PR (#26) that showcases these proposed changes.

---

Proposed Changes

• Node Support:
  • Dropping support for Node.js versions that have been End-of-Life (EOL) for an extended period would be beneficial. While this is a critical topic, it would simplify our CI Pipeline and enable the use of modern syntax and tooling.
  • Focusing on supported Node versions would allow us to adopt and promote more modern features, moving the community forward.
  • Packages needing support for older Node versions could still transpile the code independently.
  • Alternative: Since this package does not rely on Node.js internals or specific dependencies, we could reduce the number of Node versions tested in CI. Officially, the package would be tested on key Node.js versions (e.g., v18 and above), with compatibility for older versions likely but not guaranteed.

New Features & Enhancements

• ESM Support

  • Use Rollup to generate a CommonJS entry point (index.cjs) from an ESM entry point (index.mjs), as demonstrated in PR Express TC Meeting - 2016-07-27 expressjs/discussions#26.
  • This approach improves compatibility with both modern and legacy build systems and enhances bundler and browser support.
  • It allows us to write modern ESM code and transpile it to CJS, bridging compatibility needs.

• Built-in TypeScript Types

  • Embed TypeScript types directly within the package to eliminate the dependency on @types/content-type.
  • Since the types for this package are minimal, including them directly improves maintainability and reduces reliance on external packages.
  • If adopted, we should deprecate the @types/content-type package.

Maintainability Improvements

• Updated CI Pipeline

  • Configure CI to test only supported Node.js versions (v18 and above) and potentially browsers if we decide to support them.
  • Replace nvm with the actions/setup-node action for better performance, leveraging its built-in caching for Node.js versions.
  • Limit CI pipeline permissions to essential scopes for security.
  • These changes mirror body-parser issue #545.

• Native Testing with node:test

  • Replace mocha and nyc with Node.js’ native test runner and c8 for code coverage.
  • This reduces dependencies and streamlines the testing setup, aligning it with Node.js standards and keeping the environment lightweight.

• ESLint Update

  • Upgrade to ESLint v9 and implement the new flat config to improve linting consistency.

• Code Formatting

  • Consider introducing Prettier for consistent code style enforcement across the project.
  • Alternatively, we could add stylistic rules directly within the ESLint configuration, maintaining a single toolchain for both style and linting needs.

---

[bjohansebas]

I think updating to ESLint 9 can wait, as we are opting to use standard or neostandard across the organization, although that's a discussion that has been going on for some time. @wesleytodd, has there been any progress on this?

[wesleytodd]

Lots going on in this proposal, just like in the PR, which will make it hard to have a discussion around. I hate to ask again for changes in the proposal, but ideally this would be an issue per thing (or a PR per thing, depending on how much work you wanted to put into it with the chance of it being throw away). I have some concerns with the points above, but others could land without much worry.

[blakeembrey]

Everything in the proposal looks great to me, except I'd skip ESM support for now. I think the dead code elimination for consumers and rollup in the dev pipeline does not outweigh the overhead for maintainers and overall package install size.

[blakeembrey]

If we're already going to support types directly, why not use TypeScript and output both .js and .d.ts files so they're guaranteed to be in sync?

[wesleytodd]

If we're already going to support types directly, why not use TypeScript

I think we should continue here: expressjs/typescript-wg#1

In general I will say though that I am opposed to TS re-writes for nearly all of the packages in jshttp for reasons 😆. Again, would like to continue that discussion in the main thread for the larger project though so it is not lost in this one package.