v4 Roadmap

[octet-stream]

I think it's time for me to start work on the next version of formdata-node. This version should be the last piece to make it fully spec-compatible. Here's what I want to do:

• [x] Remove all additional APIs, keep only what is compatible with the spec. This change will not affect anyone who already dropped use of them;
• [x] Remove builtin multipart/form-data encoder and rely on support of it in HTTP clients and form-data-encoder package;
• [x] I should probably remove CJS support and focus on ESM, but I was thinking if it is not too early for that... My original plan was to drop it by the Node 12 EOL, so developers who depends on formdata-node have smoothen transitional period before they adopt ESM and I can focus on supporting only one major version of the package; I decided to keep CJS support for now and remove in v5, if this version will be released at all;
• [x] If I decide to drop CJS, I will also need to get rid of the File class implementation in favour of the one provided by fetch-blob; I'll keep fetch-blob at v2 because I need CJS support. Maybe I will vendor it later or include a part of it in formdata-node package if that will make any sense;
• [ ] Run tests against WPT maybe? This probably will be achieved later;
• [x] Maybe simplify documentation. I think a reference to MDN will be enough when the module becomes fully spec-compliant. I decided to just remove all removed APIs from docs and rewrite examples.

[jimmywarting]

I would say: go for ESM only, but first wait for web-stream-polyfill to reduce the package size. that 8MB was not so well received among others. Or don't go ESM just yet, some ppl actually preferred your CJS version over my ESM only package for that reason alone. both yours and mine will become a bit obsolete now when nodejs plans to ships File and FormData into core as well.

[octet-stream]

Or don't go ESM just yet, some ppl actually preferred your CJS version over my ESM only package for that reason alone.

Yeah, because people still need CJS (I personally use it at least for prototyping, because I want to use ts-node-dev which have no ESM support) I may keep it in v4. But technically, people can stick with v3, because v4 is more of a housekeeping release.

both yours and mine will become a bit obsolete now when nodejs plans to ships File and FormData into core as well.

Yeah, the v4 would probably be the last version of my package at least for this reason.

[jimmywarting]

sad part is that you will be stuck with a older version of fetch-blob and be forced to use a own File Class as of now

[octet-stream]

Yeah, I'd prefer to update to v3, because it passes WPT.