v6.0.0

Breaking changes

• The Compression and DictionarySize enums are gone, the api takes string literals.

  // before
  import { Compression, DictionarySize } from 'node-pkware'
  implode(Compression.Binary, DictionarySize.Large)
  // after
  implode('binary', 'large')

  • the compression type is CompressionType = 'binary' | 'ascii' (the type and the exported name
    were Compression), the dictionary size is DictionarySize = 'small' | 'medium' | 'large'
  • both apis take the same strings now. Until 5.9.2 the stream api expected the enum members while
    the simple api expected the strings, so the same call did not work for the two of them.

Fixes

• The simple implode lost the end of its output when the compressed data was bigger than the
  input. A literal in binary mode is a marker bit plus eight data bits, so incompressible input
  grows by about 12.5%, but the output buffer was allocated as input + 3 + 2 bytes and the writes
  past its end were silently dropped by the typed array. 4096 random bytes came out as 4101 bytes
  which could not be decompressed; they take 4603 bytes now and the round trip is lossless.
• Inputs shorter than two bytes threw from the simple api. A one byte input ended in an
  AbortedError; it compresses to 6 bytes now and decompresses back.
• The stream encoder's output depended on how the input was split into chunks. The encoder
  dropped its input buffer at every chunk boundary, so a repetition was cut short at the end of a
  chunk. The cli (which pipes the file in 64 KB chunks) and the code path (which passes the whole
  buffer to the simple api) produced different bytes for the same file — 612 566 against 573 104
  bytes for a level file. The encoder waits for the next chunk now, so both paths produce the same
  573 104 bytes. (#6)
• toBuffer() called back with the whole heap of its internal buffer, including the unused
  capacity, instead of the bytes that were written. It returns the used slice now.

Improvements

• The stream encoder compresses better. It uses the same match finder as the simple api (a two
  byte hash of the latest occurrence) instead of the naive backward search it had, so its output is
  about 6% smaller on real level files (612 566 → 573 104 bytes), and the two apis produce identical
  bytes for the same input.
• The simple api accepts a Uint8Array too. new Explode(input) and
  new Implode(input, compressionType, dictionarySize) take ArrayBufferLike | Uint8Array, so a
  Buffer — or a slice of one, like the compressed part of a partially compressed file — can be
  passed without copying it.
• The documentation. Every description is a complete sentence, the public types and the errors are
  documented, and the same concept is described with the same wording everywhere — the generated
  .d.ts files, which is what most editors show, carry all of it.

Full Changelog: v5.9.2...v6.0.0