@remix-run/headers subclassing of DOM Headers may cause future web compatibility issues (like smoosh-gate)

[frontsideair]

I've been looking at @remix-run/headers and this part jumped at me:

Drop-in Enhancement: As a subclass of the standard Headers object, it can be used anywhere a Headers object is expected, providing progressive enhancement to your existing code.

It's listed as a strength, and in some ways it is, but it may cause compatibility issues in case WHATWG decides to enhance the Headers spec. If this becomes widespread, another smoosh-gate is waiting us.

Let me demonstrate with an example. Let's say we created a Headers instance and added contentType via the Remix helpers. If we pass it to fetch it will still work, because the consumer can still access .get('contentType'). But the issue arises if WHATWG decides to add their own .contentType property in the future. Some scenarios:

• They don't notice that Remix uses a subclass and ship an API incompatible version (like an array instead of an object). In this case, all current Remix apps will start crashing on new engines.
• They notice this and try to mimic Remix API decisions. In this case there won't be any breakage, but this will limit the working group's decisions and they may not be able implement an improved design.
• They notice this and try to sidestep it like how array.flat was landed. In this case, we get an inferior name so the ecosystem doesn't break.

I believe this is less than ideal for any possible scenario. So my suggestion would be to back away from using a subclass and make it explicit by using a method such as remixHeaders.toHeaders() to convert when passing to 3rd party consumers. It's not a big hassle, but save the ecosystem in the long run.

[MichaelDeBoey]

CC/ @brophdawg11 @mjackson