Breaking and Potentially Breaking Changes

• Minimum supported node version is now v10.16.0
• No more constructor
• Use 'close' event instead of 'finish' event when you need to execute
  something whether the busboy stream encountered an error or not
• Some 'field' and 'file' event handler parameters have changed
  • Truncated flags, encoding, and mime type information have been consolidated
    into a single object passed to the event handlers
• Some error messages have changed
• Switched text decoding from using an older (and slower) reference TextDecoder
  implementation to using encodings/charsets supported internally by node
  (via either core encodings or built-in ICU). If you need to support less
  common encodings/charsets, then make sure you are using a build of node that
  contains the full ICU database for maximum compatibility.
• (multipart/form-data) Stricter header parser
• (multipart/form-data) Smaller max allowable (total) header size (per part) to align with
  node's http parser (80KB -> 16KB)

Misc. Changes

• Faster non-file fields handling due to switching method of handling
  transcoding of strings
• Implementation simplified overall due to advancements made in node streams
  since the original implementation
• (multipart/form-data) Faster parsing (partly from streamsearch improvements)
• (multipart/form-data) No longer uses dicer, uses streamsearch directly

Benchmarks

Setup

Node version used: v16.13.1

Package versions used:

• busboy - v0.3.1
  • Already takes into account streamsearch v1.x perf improvements
    via dicer
• busboy - v1.0.0
• formidable - v2.0.1
  • formidable has a streaming urlencoded parser, but it is not used
    by formidable currently when parsing urlencoded forms, however I have
    included benchmarks for this parser in the urlencoded benchmarks for
    completeness
• multiparty - v4.2.2

Note: In these benchmarks, formidable technically has a bit of an edge
compared to the other modules since the code to benchmark it is using the
individual parsers (multipart and urlencoded) directly, skipping a lot of extra
code that would ordinarily execute while parsing a request. This was done this
way as it was the easiest way to benchmark formidable without saving files to
disk, which would otherwise put formidable at a disadvantage because the other
modules are not saving files to disk.

Note 2: bench-urlencoded-fields-100pairs-small.js takes into account extra
non-parsing-related logic (e.g. creating new instances and other setup code) so
it's not strictly a measure of parsing performance. The reason for this is that
the benchmark parses the same request multiple times in an async loop, since the
modules parsing an urlencoded request is very quick and may not give V8 time to
optimize functions, etc. and the modules' parser instances generally cannot be
reused.

Results

• bench-multipart-fields-100mb-small.js

  Package	Average time (ms)	Average max RSS (MB)
  busboy (pre-1.0)	15077	338
  busboy	426	145
  formidable	3600	143
  multiparty	1450	144

• bench-multipart-fields-100mb-big.js

  Package	Average time (ms)	Average max RSS (MB)
  busboy (pre-1.0)	1160	270
  busboy	398	186
  formidable	3640	187
  multiparty	1510	186

• bench-multipart-files-100mb-small.js

  Package	Average time (ms)	Average max RSS (MB)
  busboy (pre-1.0)	433	149
  busboy	377	145
  formidable	3700	143
  multiparty	1400	145

• bench-multipart-files-100mb-big.js

  Package	Average time (ms)	Average max RSS (MB)
  busboy (pre-1.0)	451	186
  busboy	398	186
  formidable	3800	187
  multiparty	1500	186

• bench-urlencoded-fields-100pairs-small.js

  Package	Average time (ms)	Average max RSS (MB)
  busboy (pre-1.0)	2700	99
  busboy	227	41
  formidable	230	41
  formidable (streaming)	260	42

• bench-urlencoded-fields-900pairs-small-alt.js

  Package	Average time (ms)	Average max RSS (MB)
  busboy (pre-1.0)	31.0	45
  busboy	5.7	34
  formidable	6.2	34
  formidable (streaming)	6.7	34