Adopt `module-sync`?

[benmccann]

With the release of Node 24 and EOL of Node 18 next month, all LTS versions of Node will support having a module-sync entry point in exports allowing CJS files to load ESM files if they do not use top-level await. It would be a nice change as it would reduce the size of the package as a CJS build would no longer be needed for CJS consumers and would help support the ecosystem moving to ESM.

This package currently supports Node 18, so it would require bumping the engines field slightly and would be a breaking change

[bjohansebas]

Express v4 and v5 use cookie@0, which means that we must keep version 0 of cookie, while version 1 of cookie is not used in any version of Express.

Releasing another major version at this moment doesn’t seem like the right move. We want to update this dependency in express-session, which means we need explicit support for Node 18. Additionally, several dependencies in the ecosystem require explicit support for Node 18, as we need to stay aligned with Express v5 support.

We also can't release a major version just for changing Node.js support, we need more changes to justify it.

I'm not very familiar with how this new option works. Why would it be necessary to use it in this package?

[benmccann]

Makes sense. It'd be a good thing to do eventually as it'd cut the package size in half, but if you need to support Node 18 then it's not much an option at the moment and probably something for the future instead.

[wesleytodd]

My understanding is that module-sync, when used with the other exports fields, can be done in a non-breaking way. I haven't tested it yet, but since IIUC this is shipped as CJS then we would also need to update to output ESM which is the real breaking change. Unless it was a dual mode package, but that would defeat the purpose of reducing the package size you wanted. So I think I would prefer to treat this as a future improvement once we are more into the world of apps being on supporting node versions (a few years maybe?).