/node_modules/minizlib/README.md

 1# minizlib
 2
 3A tiny fast zlib stream built on [minipass](http://npm.im/minipass)
 4and Node.js's zlib binding.
 5
 6This module was created to serve the needs of
 7[node-tar](http://npm.im/tar) v2.  If your needs are different, then
 8it may not be for you.
 9
10## How does this differ from the streams in `require('zlib')`?
11
12First, there are no convenience methods to compress or decompress a
13buffer.  If you want those, use the built-in `zlib` module.  This is
14only streams.
15
16This module compresses and decompresses the data as fast as you feed
17it in.  It is synchronous, and runs on the main process thread.  Zlib
18operations can be high CPU, but they're very fast, and doing it this
19way means much less bookkeeping and artificial deferral.
20
21Node's built in zlib streams are built on top of `stream.Transform`.
22They do the maximally safe thing with respect to consistent
23asynchrony, buffering, and backpressure.
24
25This module _does_ support backpressure, and will buffer output chunks
26that are not consumed, but is less of a mediator between the input and
27output.  There is no high or low watermarks, no state objects, and so
28artificial async deferrals.  It will not protect you from Zalgo.
29
30If you write, data will be emitted right away.  If you write
31everything synchronously in one tick, and you are listening to the
32`data` event to consume it, then it'll all be emitted right away in
33that same tick.  If you want data to be emitted in the next tick, then
34write it in the next tick.
35
36It is thus the responsibility of the reader and writer to manage their
37own consumption and process execution flow.
38
39The goal is to compress and decompress as fast as possible, even for
40files that are too large to store all in one buffer.
41
42The API is very similar to the built-in zlib module.  There are
43classes that you instantiate with `new` and they are streams that can
44be piped together.