fix(fetch): Explicitly check for FormData type

[timdp]

On one hand, the current implementation of the core isFormDataLike helper is:

undici/lib/core/util.js

Line 328 in 2ea8f03

return chunk && chunk.constructor && chunk.constructor.name === 'FormData'

On the other hand, the Fetch code has an actual FormData implementation.

The latter's constructor.name is 'FormData', so the combination of the two does work. So far, so good.

Now, I'm using esbuild to bundle undici into my app. Because of some naming conflict, it renames the class to FormData3. And then, all hell breaks loose.

To avoid that issue, this PR makes the Fetch part explicitly check the type of the given object.

It'd probably be better to update the core helper instead. I'd originally started to do that. Unfortunately, it introduced a circular dependency. It seemed solvable, but I didn't want to start moving things around just yet.

[targos]

Is it spec-compliant to do an instanceof check? This would remove support for alternative implementations of FormData.

[ronag]

Is it spec-compliant to do an instanceof check? This would remove support for alternative implementations of FormData.

It still does the FormDataLike check.

[NMinhNguyen]

What if we did something like static name = 'FormData' in the class definition instead? That would avoid needing an instanceof check which is a common source of problems in cross-realm code.

[KhafraDev]

Not needed, the current util.isFormDataLike check is still there if the instanceof check fails. Plus, FormData.name already exists because it's a class.

[NMinhNguyen]

Not needed, the current util.isFormDataLike check is still there if the instanceof check fails.

So there can't be a case where a FormData class is both mangled and imported from another realm (or perhaps another version of the same package on npm) and is passed to isFormDataLike?

Plus, FormData.name already exists because it's a class.

That's precisely why defining it as a static property would override its potentially mangled name.

[ronag]

I don't think this makes things worse. Might be room for further improvement as per @NMinhNguyen's comments.