V3: ESM+CJS, automatic split combined cookies, & general API cleanup

[nfriedly]

This has a few big changes all rolled into one:

• Converted the library to ESM and added a script to automatically build a CJS version on pre-commit.
  • I think I got everything right in package.json to make it work in either type of project.
• splitCookieString() is now called automatically when appropriate, with a new split option to override the behavior
• The documented API is now a single named export: parseSetCookie(input, options)
  • but all previous API methods/names remain present for backwards compatibility - in both the CJS and ESM versions

I think this will be a non-breaking change for most, if not all, users. But I'm not 100% sure and I had previously stated that the automatic splitCookieString() would be in a major version, so calling this 3.0 feels like the right move.

@bytesnz, @thib3113, @realityking, @benmccann, @renatoaraujoc, & @LenweSaralonde would you each mind giving this a shot sometime in the next week or two? (Or let me know if you need more time than that.)

You can install this branch in your local project with this command:

npm install git+https://github.com/nfriedly/set-cookie-parser#v3

Fixes #73
Fixes #50
Relates to #68

[nfriedly]

This is just a copy of of lib/set-cookie.js, but with the exports at then end changed to cjs.

[nfriedly]

I'm going to go ahead and release this in a few days if I don't hear back from anyone before then.

[thib3113]

I doesn't have the time to try sorry ...

But, some things seems strange, why did you commit the "dist" ?
And why not using the CI to generate it, and release ? ( so you can use "Provenance" on npm, to certify that your package match the code in the repository example ) .

Also, you check if git is not clean in CI ? ( strange ? why ? ) .

[nfriedly]

But, some things seems strange, why did you commit the "dist" ?

That's a good point. I started doing this for TypeScript projects, because it's nice to be able to check out a git repo and use it without having to compile first, but for something like this, it's technically usable without compiling. Maybe I'll remove that for this one.

And why not using the CI to generate it, and release ? ( so you can use "Provenance" on npm, to certify that your package match the code in the repository example ) .

It actually does both! The npm test command automatically builds first, and tagged versions are published with the provenance flag:

set-cookie-parser/.github/workflows/node.js.yml

Line 43 in 2979b69

run: npm publish --provenance

Also, you check if git is not clean in CI ? ( strange ? why ? ) .

That's to make sure they don't get out of sync, but if I switch to only building in CI, then I can remove that check.

[thib3113]

That's a good point. I started doing this for TypeScript projects, because it's nice to be able to check out a git repo and use it without having to compile first, but for something like this, it's technically usable without compiling. Maybe I'll remove that for this one.

I understand your point, and it's your project, so I respect your choice! It just feels a bit 'non-standard' to me.

In most professional workflows I've seen, we usually do the opposite: the repo stays 100% source-only. Generally, users either fetch the compiled assets from a Release/NPM or build it themselves after cloning. Committing generated files is often avoided because it adds a lot of noise to pull requests and can lead to merge conflicts.