@wesleytodd Apologies, I'm unfamiliar with these practices currently (for now) so I'm getting the gist but not 100% certain exactly what sort of change you would like me to do (be that in this PR or in a separate PR); hence I was under the impression that simply changing the error message would be sufficient. If you could provide an example of the change I should make that would not be breaking in this instance, I would really appreciate that.

(had I known that changing the error message itself would be considered a breaking change, I probably would've opened an issue first 😅)

For clarity, my current understanding is that currently the errors are thrown only with messages. Therefore, current users of this library may potentially be handling errors by checking against the error's .message property, thus changing the error messages is breaking and should be saved for a major release. For now, keeping the error messages as is but simply adding an appropriate .code property to the error objects will be non-breaking, and allow people to switch to error handling via the .code property.

If that's the case, then I'd just need to know the preferred way you'd like me to implement this, whether I simply do something like

// change this
default:
  throw new TypeError('option sameSite is invalid');
  
// to this
default:
  var sameSiteError = new TypeError('option sameSite is invalid');
  sameSiteError.code = 'ERR_INVALID_ARG_VALUE';
  throw sameSiteError;

Or if it'd be preferable to create custom error objects with the appropriate codes and throw those as required.