cc @Ethan-Arrowood

Since @types/node relies on undici-types, people will notice that .formData() is "deprecated" if they use typescript. I feel very strongly that we should prevent people from using it, even if we did everything correctly, because it's an API that is totally unsuitable for any use case I can think of.

Referring to multipart/form-data parsing, urlencoded is fine I guess.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 93.81%. Comparing base (a3f494b) to head (2f2b6d6).

@@           Coverage Diff           @@
##             main    #2892   +/-   ##
=======================================
  Coverage   93.81%   93.81%           
=======================================
  Files          85       85           
  Lines       23410    23410           
=======================================
  Hits        21961    21961           
  Misses       1449     1449           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

hi @KhafraDev

I'm one of those devs and I've tried to find a good explanation of why it's deprecated but came up empty handed. I admit the form-data API isn't exactly the friendliest, but it feels like overkill to mark it as deprecated. I'm no node-js expert, so I'm assuming there's some good arguments here, I just can't seem to find any.

All examples I could find revolve around JSON compatible APIs, but I'm sending a registration form (name, email & avatar).

• I don't want to convert the image to base64
• I can't mix in binary with standard JSON in a single request
• I don't want to separate the data endpoint and image endpoint

Using a formPost seemed like the obvious choice for the frontend. The backend can "simply" do the const formData = await request.formData() call. No extra deps, fairly easy to use and it's baked into most environments.

Do you happen to have a resource handy? I'd really like to understand the reasoning behind this before I go ahead and add a library to a web worker.

It wasn't deprecated for semantics, but because of how it's implemented. It's implemented the same in every other environment FWIW: the body is buffered in memory and then the "form data" body is parsed. The biggest issue therefore, and the reason for the deprecation, is that multipart/form-data is oftentimes used to send large files, which leads to potential DOSing on the backend.

Semantically it sucks too, but it wasn't a contributing factor in why it was deprecated. It's called "formData" but parses both multipart/form-data and x-www-form-urlencoded bodies. You cannot limit the body size nor do you have any control over how the body is parsed (busboy and @fastify/busboy both give fine grained control). The spec does not include steps to parse form data bodies, which means most implementations have quirks that do/don't work in other environments.

My recommendation is to use either busboy or @fastify/busboy (0 deps) and pipe a Response's body to it.

import { Readable } from 'node:stream'

const busboy = ...
const response = new Response(...)

if (response.body !== null) {
    Readable.fromWeb(response.body).pipe(busboy)
}

There are other libraries such as https://github.com/mjackson/remix-the-web/tree/main/packages/multipart-parser but I have never used it.

@KhafraDev thank you. You have been my "TIL" moment! Going to switch to @fastify/busboy per recommendation.

Considering that mitigating DoS from large payloads is a server-side responsibility and the API is meant for simple convenience rather than fine-grained control, deprecating .formData() doesn't seem to be the right course of action.