V3 changes

[nfriedly]

I'm thinking about the changes I'd like to see in a version 3. The two big ones that I'd like to get in are:

• Automatically run splitCookieString() when when the input has a string for the header value (not an array)
  • Probably with a new option to explicitly always/never run it, and only decide based on input when it's unset
• Offer an ESM version of the library

Things I'm considering but haven't yet decided one way or the other:

• Ship both ESM and CJS variations or make 3.x exclusively ESM?
• Convert the library to typescript? (Would help with the above, although TypeScript seems to break the "naked" import in CJS.)
• Split parse() into parseToArray() and parseToMap() to make for simpler typing? (Or support all 3?)
  • I think I won't do this one. I hadn't realized typescript supported overloaded signatures, so I can make the typing work correctly with a single function.

[bytesnz]

I reckon for the splitting, just adding an additional function of parseToMap() would be good (and keeping the current parse() as is. I'm sure quite a few people will be currently doing:

const cookies = setCookieParser.parse(setCookieParser.splitCookieString(res.headers.get('set-cookie'))).reduce((obj, c) => { obj[c.name] = c; return obj})

Just adding the parseToMap() instead of replacing parse() with parseToArray() and parseToMap() will mean no changes required when upgrading.

[nfriedly]

There's already a built-in map option that does basically that internally. I was thinking it would be difficult to represent in TypeScript, but it turns out that it's not so hard after all - TypeScript can statically determine the output type based on the input options.

If I was starting over from scratch, I'd probably do like you said, but since the existing API is there and doesn't seem to be causing any trouble, I'm going to avoid an unnecessary breaking change leave it as-is.