`FormData` implementation/types mismatch

[ernestostifano]

Version

v22.6.0

Platform

Darwin esmbp2023 23.5.0 Darwin Kernel Version 23.5.0: Wed May  1 20:17:33 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6031 arm64

Subsystem

Fetch

What steps will reproduce the bug?

Regarding FormData type definition (https://github.com/nodejs/node/blob/main/deps/undici/src/types/formdata.d.ts):

The majority of methods are defined as instance methods (e.g., append, set, getAll, etc.):

// EXAMPLE
export declare class FormData {
  // ...
  append (name: string, value: unknown, fileName?: string): void
  // ...
}

But the following methods are defined as properties:

• forEach
• keys
• values
• entries
• Symbol.iterator

// EXAMPLE
export declare class FormData {
  // ...
  forEach: (
    callbackfn: (value: FormDataEntryValue, key: string, iterable: FormData) => void,
    thisArg?: unknown
  ) => void
  // ...
}

This prevents extending those methods when extending FormData:

// EXAMPLE
class StrictFormData<T> extends FormData {
    /** [MDN Reference](https://developer.mozilla.org/docs/Web/API/FormData/entries) */
    entries = <TK extends keyof T & string>(): IterableIterator<
        [TK, T[TK]]
    > => {
        // ERROR: TS2855: Class field entries defined by the parent class is not accessible in the child class via super.
        return super.entries() as IterableIterator<[TK, T[TK]]>;
    };
}

// EXAMPLE
class StrictFormData<T> extends FormData {
    /** [MDN Reference](https://developer.mozilla.org/docs/Web/API/FormData/entries) */
    // ERROR: TS2425: Class FormData defines instance member property entries, but extended class StrictFormData<T> defines it as instance member function.
    entries<TK extends keyof T & string>(): IterableIterator<[TK, T[TK]]> {
        // ERROR: TS2855: Class field entries defined by the parent class is not accessible in the child class via super.
        return super.entries() as IterableIterator<[TK, T[TK]]>;
    }
}

Is it a mistake in the type definitions?

When looking at the implementation (https://github.com/nodejs/node/blob/main/deps/undici/src/lib/web/fetch/formdata.js) I don't see any of those methods added, neither "statically", nor dynamically upon construction. I might be missing something because exactly those atypically defined methods are the ones that I cannot find in the implementation.

Thanks!

How often does it reproduce? Is there a required condition?

See above.

What is the expected behavior? Why is that the expected behavior?

See above.

What do you see instead?

See above.

Additional information

See above.

[ernestostifano]

Ok, never mind, found those methods are added via iteratorMixin (https://github.com/nodejs/node/blob/main/deps/undici/src/lib/web/fetch/util.js). So the types seem correct.

[ernestostifano]

On second thought, given that the methods are being added to the prototype:

Object.defineProperties(object.prototype, {
    ...properties,
    [Symbol.iterator]: {
      writable: true,
      enumerable: false,
      configurable: true,
      value: properties.entries.value
    }
  })

They should be considered instance methods, extensible and accessible via super. So probably types should be corrected to:

export declare class FormData {
  forEach(
    callbackfn: (value: FormDataEntryValue, key: string, iterable: FormData) => void,
    thisArg?: unknown
  ): void;

  keys(): SpecIterableIterator<string>;

  values(): SpecIterableIterator<FormDataEntryValue>;

  entries(): SpecIterableIterator<[string, FormDataEntryValue]>;

  [Symbol.iterator](): SpecIterableIterator<[string, FormDataEntryValue]>;
}

Happy to open a PR if right. Please let me know.

Here we can see TypeScript's definition in DOM's library: https://github.com/microsoft/TypeScript/blob/b504a1eed45e35b5f54694a1e0a09f35d0a5663c/src/lib/dom.generated.d.ts#L9826

Related:

• The child class should not be able to access the class field defined by the parent class via super microsoft/TypeScript#54054
• Accessing property on super should be a type error microsoft/TypeScript#35314