add specific error messages, error codes, to serialize validation

[jonchurch]

draft take on #163 using a custom error class, and adding in the valid type of arg when its easy to do so.

[jonchurch]

No bencmarks for serialize yet, so not posting bench

[jonchurch]

@MaoShizhong don't mean to step on your contribution #163 here, started writing this before I saw your PR.

@wesleytodd I can see how error messages could be considered breaking changes for a package as widely used as cookie, aIthough I don't like it or what people would be depending on. The original change I was doing was just adding in the enriched error messages.

It does switch from TypeError to extending Error class, which is breaking since we were throwing TypeErrors before. instanceof CookieError !== 'TypeError'. I can swap it to TypeError extension, which would be nonbreaking for instanceof. But idk that feels weird? Should be named CookieSerializeValidationError or w/e at that point, instead of a generic error.

The breaking parts can be backed out, and @MaoShizhong could land the error codes independently in a minor.

[wesleytodd]

I can see how error messages could be considered breaking changes for a package as widely used as cookie, aIthough I don't like it or what people would be depending on. The original change I was doing was just adding in the enriched error messages.

I would not consider this a breaking change IF we had provided .code previously. If there is a better documented way to type check an error then I am good (even if that is the less ideal typeof check which couples to implementation details). I think the issue here is that both are likely breaking in this PR.

Maybe you could break them apart and do a .code addition first?

[mao-sz]

I would not consider this a breaking change IF we had provided .code previously.

Given the above discussion, this perhaps may be a naive solution and not something I like particularly much, but would it be viable to add something like

declare global {
  interface TypeError {
    code: string;
  }
}

to src/index.ts somewhere?

Feels ugly to me but shouldn't be breaking as it'll retain the TypeError constructor but allow us to add .code. Then something like a custom class could come in a future major.

A caveat would be that it's not particularly obvious to consumers that the thrown error would contain a non-standard TypeError property .code, though AFAIK it's not documented in the JSDoc that stringifyCookie and stringifySetCookie can throw anyway.

I wonder if the JSDoc for both of those functions could also include

/**
 * @throws {TypeError} when invalid option value provided. Error code in .code property.
 */