Postconditions: what we check

• loadAsync · load-invalid-zip

  error
  Whendata is not valid zip data, is a Node.js stream, has unsupported features (multi-volume, password protected), or CRC32 mismatch when checkCRC32 is true
  ThrowsError — message describes the failure: 'JSZip can\'t accept a stream when loading a zip file.', 'Corrupted zip : CRC32 mismatch', or generic parse error
  Required handlingCaller MUST wrap loadAsync() in try-catch. Invalid, corrupted, or malicious zip files reject the promise. This is especially critical when loading user-uploaded files (docx, xlsx, pptx, zip) where content is untrusted.
  costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
  Sources[1][2]
• generateAsync · generate-unsupported-type

  error
  Whenrequested output type (uint8array, arraybuffer, blob, nodebuffer) is not available in current browser environment
  ThrowsError — type not supported in this environment
  Required handlingCaller MUST wrap generateAsync() in try-catch. In browser environments, check JSZip.support[type] before calling generateAsync with that type. On Node.js, nodebuffer is always supported.
  costlowin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
  Sources[3]
• async · file-async-no-try-catch

  error
  Whenzip.files['name'].async(type) called without try-catch wrapping the await expression, in an async function that processes zip file contents
  ThrowsError — decompression failure from pako ('data error', 'invalid block type', 'invalid stored block lengths', 'invalid code lengths set'). Also throws Error('<type> is not supported by this platform') when output type unavailable in current environment (e.g. 'blob' requested in Node.js).
  Required handlingCaller MUST wrap .async() calls in try-catch. Files inside a zip archive may be individually corrupted, contain malformed DEFLATE data, or request an output type unavailable in the current runtime. This is especially critical when processing untrusted user-uploaded zip archives (docx, xlsx, pptx, zip) where individual file entries may be corrupted independently of the archive container. A zip that passes loadAsync() validation can still have individual entries that fail decompression.
  costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
  Sources[4][5][6]
• async · file-async-unsupported-type

  warning
  Whenzip.files['name'].async(type) called with an output type that is not supported in the current runtime environment: 'blob' in Node.js, 'uint8array'/'arraybuffer' in very old browsers without typed array support
  ThrowsError: '<type> is not supported by this platform' (thrown synchronously within the Promise from utils.checkSupport())
  Required handlingCaller SHOULD check JSZip.support[type] before calling .async(type) in browser environments where type availability varies. On Node.js, use 'nodebuffer' as the standard output type. The 'blob' type is only available in browser environments with Blob support.
  costlowin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
  Sources[4][7]
• generateNodeStream · generate-node-stream-no-error-listener

  error
  Whenzip.generateNodeStream() called without registering an 'error' event listener on the returned ReadableStream, and/or without calling .pipe() to a writable stream that handles errors. DEFLATE compression of individual zip entries can fail mid-stream, emitting an 'error' event on the readable stream. Per Node.js EventEmitter semantics, an unhandled 'error' event causes an uncaught exception that crashes the process.
  ThrowsError emitted via stream 'error' event (not thrown — does NOT reject a Promise). Error message describes the compression failure. If no 'error' listener is registered on the returned stream, Node.js throws an unhandled exception: "Error: [compression error message]" and terminates the process.
  Required handlingCaller MUST register an 'error' event listener on the stream returned by generateNodeStream() before piping. When piping, also handle errors on the writable stream. The common pattern: zip.generateNodeStream({streamFiles:true}) .on('error', (err) => console.error('Zip error:', err)) .pipe(outputStream) .on('finish', () => console.log('Done')); Note: using .pipe() does NOT automatically propagate stream errors. Both the readable and writable streams must have separate error handlers.
  costhighin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
  Sources[8][6][9]
• generateNodeStream · generate-node-stream-unsupported-env

  error
  Whenzip.generateNodeStream() called in a browser environment or in a Node.js environment where the 'readable-stream' package is unavailable. The internal checkSupport('nodestream') check fails synchronously before the stream is created. Also throws if the 'type' option is set to anything other than 'nodebuffer' (e.g., 'blob', 'uint8array') — these types are explicitly rejected by toNodejsStream() with "is not supported by this method".
  ThrowsError thrown synchronously (not via stream): 'nodestream is not supported by this platform' when the environment lacks readable-stream support. Error thrown synchronously: '<type> is not supported by this method' when a non-nodebuffer type is passed via options.type.
  Required handlingUse generateNodeStream() only in Node.js server environments. Always use the default type ('nodebuffer'). In environments where browser/Node.js compatibility is uncertain, use generateAsync() instead which works in both environments. Wrap in try-catch if called with dynamic options to catch the synchronous throw.
  costlowin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
  Sources[6][10]
• nodeStream · file-node-stream-no-error-listener

  error
  Whenzip.files['name'].nodeStream() called without registering an 'error' event listener on the returned ReadableStream, and/or without calling .pipe() to a writable stream that handles errors. DEFLATE decompression of a single file entry can fail mid-stream (corrupted entry, malformed DEFLATE data, CRC32 mismatch), emitting an 'error' event on the readable stream. Per Node.js EventEmitter semantics, an unhandled 'error' event causes an uncaught exception that crashes the process.
  ThrowsError emitted via stream 'error' event (not thrown — does NOT reject a Promise). Error message describes the decompression failure ('invalid block type', 'invalid stored block lengths', CRC32 mismatch). If no 'error' listener is registered on the returned stream, Node.js throws an unhandled exception and terminates the process.
  Required handlingCaller MUST register an 'error' event listener on the stream returned by zip.file('name').nodeStream() before piping. When piping, also handle errors on the writable stream. The common pattern: zip.files['large.bin'].nodeStream() .on('error', (err) => console.error('Entry decode error:', err)) .pipe(outputStream) .on('finish', () => console.log('Done')); Note: using .pipe() does NOT automatically propagate stream errors. Both the readable and writable streams must have separate error handlers. This is critical when streaming user-uploaded zip entries to HTTP responses — an uncaught decode error kills the entire server process.
  costhighin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
  Sources[11][5][6][8]
• nodeStream · file-node-stream-unsupported-type

  error
  Whenzip.files['name'].nodeStream(type) called with type other than 'nodebuffer' (e.g. 'blob', 'uint8array', 'arraybuffer'). The internal toNodejsStream() check rejects non-nodebuffer types synchronously per lib/stream/StreamHelper.js line 199-205: "throw new Error(this._outputType + ' is not supported by this method')". Also throws synchronously via utils.checkSupport('nodestream') when readable-stream support is unavailable (browser environments).
  ThrowsError thrown synchronously (not via stream): '<type> is not supported by this method' when a non-nodebuffer type is passed. Error thrown synchronously: 'nodestream is not supported by this platform' when the runtime lacks readable-stream support.
  Required handlingUse nodeStream() only with the default 'nodebuffer' type (or no type argument) in Node.js server environments. If the type is dynamic or environment-dependent, wrap the call in try-catch to catch the synchronous throw before the stream is constructed. In browser environments, use .async('uint8array') instead.
  costlowin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
  Sources[6][10]
• generateInternalStream · generate-internal-stream-no-error-listener

  error
  Whenzip.generateInternalStream(options) called with the event-listener pattern (.on('data', ...).on('end', ...)) WITHOUT registering an .on('error', ...) handler. Per Node.js EventEmitter semantics emulated by JSZipStreamHelper, unhandled 'error' events bubble up as uncaught exceptions. ALL errors flow through the 'error' event (per lib/object.js line 359-362): synchronous option-validation errors ('No output type specified', unsupported platform types) are caught and re-emitted as stream errors, identical to async DEFLATE compression failures mid-stream.
  ThrowsError emitted via 'error' event on the returned JSZipStreamHelper. Error message describes the cause: 'No output type specified', '<type> is not supported by this platform', or DEFLATE compression failure ('invalid block type', 'invalid stored block lengths'). If the caller uses the on('data')/on('end') pattern WITHOUT on('error'), unhandled errors cause uncaught exceptions per EventEmitter semantics.
  Required handlingCaller MUST register an .on('error', ...) handler on the StreamHelper before consuming with on('data')/on('end'). The recommended pattern: zip.generateInternalStream({ type: 'uint8array', streamFiles: true }) .on('data', (chunk, meta) => uploadChunk(chunk)) .on('end', () => finalize()) .on('error', (err) => console.error('Zip stream error:', err)); Alternatively, callers using .accumulate() get a Promise that REJECTS on error — handle via try/await/catch or .catch(). Alternatively, callers using .toNodejsStream() get a Node.js Readable with the same on('error') requirement as generateNodeStream().
  costhighin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
  Sources[12][13][14][6]
• generateInternalStream · generate-internal-stream-accumulate-unhandled-rejection

  error
  Whenzip.generateInternalStream(options).accumulate() called without await, try-catch around the await, or .catch() on the returned Promise. The accumulate() helper reads the stream end-to-end and resolves with the full content OR rejects on stream 'error' event. Unhandled promise rejections degrade to UnhandledPromiseRejection warnings in newer Node.js and silent data loss in older runtimes.
  ThrowsPromise rejects with Error describing the underlying failure: option validation errors caught synchronously and re-emitted ('No output type specified', unsupported platform), or DEFLATE compression failures. The rejection includes the same error messages as the on('error') path since both flow from the same GenericWorker('error') emission.
  Required handlingCaller MUST wrap accumulate() with try-catch around await OR attach a .catch() handler: try { const buffer = await zip.generateInternalStream({ type: 'nodebuffer' }) .accumulate(); return buffer; } catch (err) { console.error('Zip generation failed:', err); throw err; } For most callers, generateAsync() is the simpler API (Promise<output> directly) and should be preferred over generateInternalStream().accumulate() unless progress reporting via the updateCallback is required.
  costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
  Sources[13][6]

Sources

Every postcondition cites at least one of these. Grouped by source type; numbered to match the footnotes above.

Research notes

Curator notes from SOURCES.md captured when the profile was written so you can verify the reasoning, not just the rules.