minipass - npm Package Compare versions

Comparing version 4.2.1 to 4.2.2

index.js

		@@ -183,33 +183,4 @@ 'use strict'
		this[ABORTED] = true
		const signal = this[SIGNAL]
		/* istanbul ignore next */
		if (this.write) this.write = () => {}
		/* istanbul ignore next */
		if (this.end) this.end = () => {}
		/* istanbul ignore next */
		if (this.pipe) this.pipe = () => {}
		/* istanbul ignore next */
		this.on = this.addListener = () => {}
		/* istanbul ignore next */
		this.off = this.removeListener = () => {}
		/* istanbul ignore next */
		this[ABORT] = () => {}
		/* istanbul ignore next */
		this.emit = () => {}
		for (const p of this[PIPES]) {
		p.unpipe()
		}
		super.removeAllListeners('data')
		super.removeAllListeners('end')
		super.removeAllListeners('drain')
		super.removeAllListeners('resume')
		this[BUFFER].length = 0
		this.readable = false
		this.writable = false
		super.emit(ABORT, signal.reason)
		super.emit('abort', signal.reason)
		super.emit('end')
		super.emit('prefinish')
		super.emit('finish')
		super.emit('close')
		this.emit('abort', this[SIGNAL].reason)
		this.destroy(this[SIGNAL].reason)
		}
		@@ -507,3 +478,6 @@
		super.emit(ERROR, data)
		const ret = super.emit('error', data)
		const ret =
		!this[SIGNAL] \|\| this.listeners('error').length
		? super.emit('error', data)
		: false
		this[MAYBE_EMIT_END]()
		@@ -596,3 +570,2 @@ return ret
		this.on('error', er => reject(er))
		this.on(ABORT, er => reject(er))
		this.on('end', () => resolve())
		@@ -627,3 +600,2 @@ })
		this.removeListener('error', onerr)
		this.removeListener(ABORT, onerr)
		this.removeListener('end', onend)
		@@ -635,3 +607,2 @@ this.pause()
		this.removeListener('error', onerr)
		this.removeListener(ABORT, onerr)
		this.removeListener('data', ondata)
		@@ -647,3 +618,2 @@ stop()
		this.once('error', onerr)
		this.once(ABORT, onerr)
		this.once('end', onend)
		@@ -670,3 +640,2 @@ this.once('data', ondata)
		this.removeListener(ERROR, stop)
		this.removeListener(ABORT, stop)
		this.removeListener('end', stop)
		@@ -684,3 +653,2 @@ stopped = true
		this.once(ERROR, stop)
		this.once(ABORT, stop)

		@@ -687,0 +655,0 @@ return {

package.json

		{
		"name": "minipass",
		"version": "4.2.1",
		"version": "4.2.2",
		"description": "minimal implementation of a PassThrough stream",
		@@ -5,0 +5,0 @@ "main": "./index.js",

437

README.md

		@@ -10,28 +10,30 @@ # minipass

		Supports `pipe()`ing (including multi-`pipe()` and backpressure transmission),
		buffering data until either a `data` event handler or `pipe()` is added (so
		you don't lose the first chunk), and most other cases where PassThrough is
		a good idea.
		Supports `pipe()`ing (including multi-`pipe()` and backpressure
		transmission), buffering data until either a `data` event handler
		or `pipe()` is added (so you don't lose the first chunk), and
		most other cases where PassThrough is a good idea.

		There is a `read()` method, but it's much more efficient to consume data
		from this stream via `'data'` events or by calling `pipe()` into some other
		stream. Calling `read()` requires the buffer to be flattened in some
		cases, which requires copying memory.
		There is a `read()` method, but it's much more efficient to
		consume data from this stream via `'data'` events or by calling
		`pipe()` into some other stream. Calling `read()` requires the
		buffer to be flattened in some cases, which requires copying
		memory.

		If you set `objectMode: true` in the options, then whatever is written will
		be emitted. Otherwise, it'll do a minimal amount of Buffer copying to
		ensure proper Streams semantics when `read(n)` is called.
		If you set `objectMode: true` in the options, then whatever is
		written will be emitted. Otherwise, it'll do a minimal amount of
		Buffer copying to ensure proper Streams semantics when `read(n)`
		is called.

		`objectMode` can also be set by doing `stream.objectMode = true`, or by
		writing any non-string/non-buffer data. `objectMode` cannot be set to
		false once it is set.
		`objectMode` can also be set by doing `stream.objectMode = true`,
		or by writing any non-string/non-buffer data. `objectMode` cannot
		be set to false once it is set.

		This is not a `through` or `through2` stream. It doesn't transform the
		data, it just passes it right through. If you want to transform the data,
		extend the class, and override the `write()` method. Once you're done
		transforming the data however you want, call `super.write()` with the
		transform output.
		This is not a `through` or `through2` stream. It doesn't
		transform the data, it just passes it right through. If you want
		to transform the data, extend the class, and override the
		`write()` method. Once you're done transforming the data however
		you want, call `super.write()` with the transform output.

		For some examples of streams that extend Minipass in various ways, check
		out:
		For some examples of streams that extend Minipass in various
		ways, check out:

		@@ -58,7 +60,7 @@ - [minizlib](http://npm.im/minizlib)

		There are several things that make Minipass streams different from (and in
		some ways superior to) Node.js core streams.
		There are several things that make Minipass streams different
		from (and in some ways superior to) Node.js core streams.

		Please read these caveats if you are familiar with node-core streams and
		intend to use Minipass streams in your programs.
		Please read these caveats if you are familiar with node-core
		streams and intend to use Minipass streams in your programs.

		@@ -71,18 +73,21 @@ You can avoid most of these differences entirely (for a very

		Minipass streams are designed to support synchronous use-cases. Thus, data
		is emitted as soon as it is available, always. It is buffered until read,
		but no longer. Another way to look at it is that Minipass streams are
		exactly as synchronous as the logic that writes into them.
		Minipass streams are designed to support synchronous use-cases.
		Thus, data is emitted as soon as it is available, always. It is
		buffered until read, but no longer. Another way to look at it is
		that Minipass streams are exactly as synchronous as the logic
		that writes into them.

		This can be surprising if your code relies on `PassThrough.write()` always
		providing data on the next tick rather than the current one, or being able
		to call `resume()` and not have the entire buffer disappear immediately.
		This can be surprising if your code relies on
		`PassThrough.write()` always providing data on the next tick
		rather than the current one, or being able to call `resume()` and
		not have the entire buffer disappear immediately.

		However, without this synchronicity guarantee, there would be no way for
		Minipass to achieve the speeds it does, or support the synchronous use
		cases that it does. Simply put, waiting takes time.
		However, without this synchronicity guarantee, there would be no
		way for Minipass to achieve the speeds it does, or support the
		synchronous use cases that it does. Simply put, waiting takes
		time.

		This non-deferring approach makes Minipass streams much easier to reason
		about, especially in the context of Promises and other flow-control
		mechanisms.
		This non-deferring approach makes Minipass streams much easier to
		reason about, especially in the context of Promises and other
		flow-control mechanisms.

		@@ -175,14 +180,15 @@ Example:

		Node.js core streams will optimistically fill up a buffer, returning `true`
		on all writes until the limit is hit, even if the data has nowhere to go.
		Then, they will not attempt to draw more data in until the buffer size dips
		below a minimum value.
		Node.js core streams will optimistically fill up a buffer,
		returning `true` on all writes until the limit is hit, even if
		the data has nowhere to go. Then, they will not attempt to draw
		more data in until the buffer size dips below a minimum value.

		Minipass streams are much simpler. The `write()` method will return `true`
		if the data has somewhere to go (which is to say, given the timing
		guarantees, that the data is already there by the time `write()` returns).
		Minipass streams are much simpler. The `write()` method will
		return `true` if the data has somewhere to go (which is to say,
		given the timing guarantees, that the data is already there by
		the time `write()` returns).

		If the data has nowhere to go, then `write()` returns false, and the data
		sits in a buffer, to be drained out immediately as soon as anyone consumes
		it.
		If the data has nowhere to go, then `write()` returns false, and
		the data sits in a buffer, to be drained out immediately as soon
		as anyone consumes it.

		@@ -194,6 +200,7 @@ Since nothing is ever buffered unnecessarily, there is much less

		Since data written to a Minipass stream is immediately written all the way
		through the pipeline, and `write()` always returns true/false based on
		whether the data was fully flushed, backpressure is communicated
		immediately to the upstream caller. This minimizes buffering.
		Since data written to a Minipass stream is immediately written
		all the way through the pipeline, and `write()` always returns
		true/false based on whether the data was fully flushed,
		backpressure is communicated immediately to the upstream caller.
		This minimizes buffering.

		@@ -226,10 +233,11 @@ Consider this case:

		Along the way, the data was buffered and deferred at each stage, and
		multiple event deferrals happened, for an unblocked pipeline where it was
		perfectly safe to write all the way through!
		Along the way, the data was buffered and deferred at each stage,
		and multiple event deferrals happened, for an unblocked pipeline
		where it was perfectly safe to write all the way through!

		Furthermore, setting a `highWaterMark` of `1024` might lead someone reading
		the code to think an advisory maximum of 1KiB is being set for the
		pipeline. However, the actual advisory buffering level is the _sum_ of
		`highWaterMark` values, since each one has its own bucket.
		Furthermore, setting a `highWaterMark` of `1024` might lead
		someone reading the code to think an advisory maximum of 1KiB is
		being set for the pipeline. However, the actual advisory
		buffering level is the _sum_ of `highWaterMark` values, since
		each one has its own bucket.

		@@ -259,20 +267,22 @@ Consider the Minipass case:

		It is extremely unlikely that you _don't_ want to buffer any data written,
		or _ever_ buffer data that can be flushed all the way through. Neither
		node-core streams nor Minipass ever fail to buffer written data, but
		node-core streams do a lot of unnecessary buffering and pausing.
		It is extremely unlikely that you _don't_ want to buffer any data
		written, or _ever_ buffer data that can be flushed all the way
		through. Neither node-core streams nor Minipass ever fail to
		buffer written data, but node-core streams do a lot of
		unnecessary buffering and pausing.

		As always, the faster implementation is the one that does less stuff and
		waits less time to do it.
		As always, the faster implementation is the one that does less
		stuff and waits less time to do it.

		### Immediately emit `end` for empty streams (when not paused)

		If a stream is not paused, and `end()` is called before writing any data
		into it, then it will emit `end` immediately.
		If a stream is not paused, and `end()` is called before writing
		any data into it, then it will emit `end` immediately.

		If you have logic that occurs on the `end` event which you don't want to
		potentially happen immediately (for example, closing file descriptors,
		moving on to the next entry in an archive parse stream, etc.) then be sure
		to call `stream.pause()` on creation, and then `stream.resume()` once you
		are ready to respond to the `end` event.
		If you have logic that occurs on the `end` event which you don't
		want to potentially happen immediately (for example, closing file
		descriptors, moving on to the next entry in an archive parse
		stream, etc.) then be sure to call `stream.pause()` on creation,
		and then `stream.resume()` once you are ready to respond to the
		`end` event.

		@@ -283,15 +293,15 @@ However, this is _usually_ not a problem because:

		One hazard of immediately emitting `'end'` is that you may not yet have had
		a chance to add a listener. In order to avoid this hazard, Minipass
		streams safely re-emit the `'end'` event if a new listener is added after
		`'end'` has been emitted.
		One hazard of immediately emitting `'end'` is that you may not
		yet have had a chance to add a listener. In order to avoid this
		hazard, Minipass streams safely re-emit the `'end'` event if a
		new listener is added after `'end'` has been emitted.

		Ie, if you do `stream.on('end', someFunction)`, and the stream has already
		emitted `end`, then it will call the handler right away. (You can think of
		this somewhat like attaching a new `.then(fn)` to a previously-resolved
		Promise.)
		Ie, if you do `stream.on('end', someFunction)`, and the stream
		has already emitted `end`, then it will call the handler right
		away. (You can think of this somewhat like attaching a new
		`.then(fn)` to a previously-resolved Promise.)

		To prevent calling handlers multiple times who would not expect multiple
		ends to occur, all listeners are removed from the `'end'` event whenever it
		is emitted.
		To prevent calling handlers multiple times who would not expect
		multiple ends to occur, all listeners are removed from the
		`'end'` event whenever it is emitted.

		@@ -321,6 +331,7 @@ ### Emit `error` When Asked

		Since Minipass streams _immediately_ process any pending data through the
		pipeline when a new pipe destination is added, this can have surprising
		effects, especially when a stream comes in from some other function and may
		or may not have data in its buffer.
		Since Minipass streams _immediately_ process any pending data
		through the pipeline when a new pipe destination is added, this
		can have surprising effects, especially when a stream comes in
		from some other function and may or may not have data in its
		buffer.

		@@ -335,4 +346,4 @@ ```js

		One solution is to create a dedicated tee-stream junction that pipes to
		both locations, and then pipe to _that_ instead.
		One solution is to create a dedicated tee-stream junction that
		pipes to both locations, and then pipe to _that_ instead.

		@@ -349,5 +360,5 @@ ```js

		The same caveat applies to `on('data')` event listeners. The first one
		added will _immediately_ receive all of the data, leaving nothing for the
		second:
		The same caveat applies to `on('data')` event listeners. The
		first one added will _immediately_ receive all of the data,
		leaving nothing for the second:

		@@ -383,4 +394,4 @@ ```js

		It's a stream! Use it like a stream and it'll most likely do what you
		want.
		It's a stream! Use it like a stream and it'll most likely do what
		you want.

		@@ -397,8 +408,9 @@ ```js

		- `encoding` How would you like the data coming _out_ of the stream to be
		encoded? Accepts any values that can be passed to `Buffer.toString()`.
		- `objectMode` Emit data exactly as it comes in. This will be flipped on
		by default if you write() something other than a string or Buffer at any
		point. Setting `objectMode: true` will prevent setting any encoding
		value.
		- `encoding` How would you like the data coming _out_ of the
		stream to be encoded? Accepts any values that can be passed to
		`Buffer.toString()`.
		- `objectMode` Emit data exactly as it comes in. This will be
		flipped on by default if you write() something other than a
		string or Buffer at any point. Setting `objectMode: true` will
		prevent setting any encoding value.
		- `async` Defaults to `false`. Set to `true` to defer data
		@@ -409,81 +421,93 @@ emission until next tick. This reduces performance slightly,
		- `signal` An `AbortSignal` that will cause the stream to unhook
		itself from everything and become as inert as possible.
		itself from everything and become as inert as possible. Note
		that providing a `signal` parameter will make `'error'` events
		no longer throw if they are unhandled, but they will still be
		emitted to handlers if any are attached.

		### API

		Implements the user-facing portions of Node.js's `Readable` and `Writable`
		streams.
		Implements the user-facing portions of Node.js's `Readable` and
		`Writable` streams.

		### Methods

		- `write(chunk, [encoding], [callback])` - Put data in. (Note that, in the
		base Minipass class, the same data will come out.) Returns `false` if
		the stream will buffer the next write, or true if it's still in "flowing"
		mode.
		- `end([chunk, [encoding]], [callback])` - Signal that you have no more
		data to write. This will queue an `end` event to be fired when all the
		data has been consumed.
		- `setEncoding(encoding)` - Set the encoding for data coming of the stream.
		This can only be done once.
		- `pause()` - No more data for a while, please. This also prevents `end`
		from being emitted for empty streams until the stream is resumed.
		- `resume()` - Resume the stream. If there's data in the buffer, it is all
		discarded. Any buffered events are immediately emitted.
		- `write(chunk, [encoding], [callback])` - Put data in. (Note
		that, in the base Minipass class, the same data will come out.)
		Returns `false` if the stream will buffer the next write, or
		true if it's still in "flowing" mode.
		- `end([chunk, [encoding]], [callback])` - Signal that you have
		no more data to write. This will queue an `end` event to be
		fired when all the data has been consumed.
		- `setEncoding(encoding)` - Set the encoding for data coming of
		the stream. This can only be done once.
		- `pause()` - No more data for a while, please. This also
		prevents `end` from being emitted for empty streams until the
		stream is resumed.
		- `resume()` - Resume the stream. If there's data in the buffer,
		it is all discarded. Any buffered events are immediately
		emitted.
		- `pipe(dest)` - Send all output to the stream provided. When
		data is emitted, it is immediately written to any and all pipe
		destinations. (Or written on next tick in `async` mode.)
		- `unpipe(dest)` - Stop piping to the destination stream. This
		is immediate, meaning that any asynchronously queued data will
		- `unpipe(dest)` - Stop piping to the destination stream. This is
		immediate, meaning that any asynchronously queued data will
		_not_ make it to the destination when running in `async` mode.
		- `options.end` - Boolean, end the destination stream when
		the source stream ends. Default `true`.
		- `options.end` - Boolean, end the destination stream when the
		source stream ends. Default `true`.
		- `options.proxyErrors` - Boolean, proxy `error` events from
		the source stream to the destination stream. Note that
		errors are _not_ proxied after the pipeline terminates,
		either due to the source emitting `'end'` or manually
		unpiping with `src.unpipe(dest)`. Default `false`.
		- `on(ev, fn)`, `emit(ev, fn)` - Minipass streams are EventEmitters. Some
		events are given special treatment, however. (See below under "events".)
		- `promise()` - Returns a Promise that resolves when the stream emits
		`end`, or rejects if the stream emits `error`.
		- `collect()` - Return a Promise that resolves on `end` with an array
		containing each chunk of data that was emitted, or rejects if the stream
		emits `error`. Note that this consumes the stream data.
		- `concat()` - Same as `collect()`, but concatenates the data into a single
		Buffer object. Will reject the returned promise if the stream is in
		objectMode, or if it goes into objectMode by the end of the data.
		- `read(n)` - Consume `n` bytes of data out of the buffer. If `n` is not
		provided, then consume all of it. If `n` bytes are not available, then
		it returns null. Note consuming streams in this way is less
		efficient, and can lead to unnecessary Buffer copying.
		- `destroy([er])` - Destroy the stream. If an error is provided, then an
		`'error'` event is emitted. If the stream has a `close()` method, and
		has not emitted a `'close'` event yet, then `stream.close()` will be
		called. Any Promises returned by `.promise()`, `.collect()` or
		`.concat()` will be rejected. After being destroyed, writing to the
		stream will emit an error. No more data will be emitted if the stream is
		destroyed, even if it was previously buffered.
		the source stream to the destination stream. Note that errors
		are _not_ proxied after the pipeline terminates, either due
		to the source emitting `'end'` or manually unpiping with
		`src.unpipe(dest)`. Default `false`.
		- `on(ev, fn)`, `emit(ev, fn)` - Minipass streams are
		EventEmitters. Some events are given special treatment,
		however. (See below under "events".)
		- `promise()` - Returns a Promise that resolves when the stream
		emits `end`, or rejects if the stream emits `error`.
		- `collect()` - Return a Promise that resolves on `end` with an
		array containing each chunk of data that was emitted, or
		rejects if the stream emits `error`. Note that this consumes
		the stream data.
		- `concat()` - Same as `collect()`, but concatenates the data
		into a single Buffer object. Will reject the returned promise
		if the stream is in objectMode, or if it goes into objectMode
		by the end of the data.
		- `read(n)` - Consume `n` bytes of data out of the buffer. If `n`
		is not provided, then consume all of it. If `n` bytes are not
		available, then it returns null. Note consuming streams in
		this way is less efficient, and can lead to unnecessary Buffer
		copying.
		- `destroy([er])` - Destroy the stream. If an error is provided,
		then an `'error'` event is emitted. If the stream has a
		`close()` method, and has not emitted a `'close'` event yet,
		then `stream.close()` will be called. Any Promises returned by
		`.promise()`, `.collect()` or `.concat()` will be rejected.
		After being destroyed, writing to the stream will emit an
		error. No more data will be emitted if the stream is destroyed,
		even if it was previously buffered.

		### Properties

		- `bufferLength` Read-only. Total number of bytes buffered, or in the case
		of objectMode, the total number of objects.
		- `encoding` The encoding that has been set. (Setting this is equivalent
		to calling `setEncoding(enc)` and has the same prohibition against
		setting multiple times.)
		- `flowing` Read-only. Boolean indicating whether a chunk written to the
		stream will be immediately emitted.
		- `emittedEnd` Read-only. Boolean indicating whether the end-ish events
		(ie, `end`, `prefinish`, `finish`) have been emitted. Note that
		listening on any end-ish event will immediateyl re-emit it if it has
		already been emitted.
		- `writable` Whether the stream is writable. Default `true`. Set to
		`false` when `end()`
		- `bufferLength` Read-only. Total number of bytes buffered, or in
		the case of objectMode, the total number of objects.
		- `encoding` The encoding that has been set. (Setting this is
		equivalent to calling `setEncoding(enc)` and has the same
		prohibition against setting multiple times.)
		- `flowing` Read-only. Boolean indicating whether a chunk written
		to the stream will be immediately emitted.
		- `emittedEnd` Read-only. Boolean indicating whether the end-ish
		events (ie, `end`, `prefinish`, `finish`) have been emitted.
		Note that listening on any end-ish event will immediateyl
		re-emit it if it has already been emitted.
		- `writable` Whether the stream is writable. Default `true`. Set
		to `false` when `end()`
		- `readable` Whether the stream is readable. Default `true`.
		- `pipes` An array of Pipe objects referencing streams that this
		stream is piping into.
		- `destroyed` A getter that indicates whether the stream was destroyed.
		- `paused` True if the stream has been explicitly paused, otherwise false.
		- `objectMode` Indicates whether the stream is in `objectMode`. Once set
		to `true`, it cannot be set to `false`.
		- `destroyed` A getter that indicates whether the stream was
		destroyed.
		- `paused` True if the stream has been explicitly paused,
		otherwise false.
		- `objectMode` Indicates whether the stream is in `objectMode`.
		Once set to `true`, it cannot be set to `false`.
		- `aborted` Readonly property set when the `AbortSignal`
		@@ -494,37 +518,41 @@ dispatches an `abort` event.

		- `data` Emitted when there's data to read. Argument is the data to read.
		This is never emitted while not flowing. If a listener is attached, that
		will resume the stream.
		- `end` Emitted when there's no more data to read. This will be emitted
		immediately for empty streams when `end()` is called. If a listener is
		attached, and `end` was already emitted, then it will be emitted again.
		All listeners are removed when `end` is emitted.
		- `prefinish` An end-ish event that follows the same logic as `end` and is
		emitted in the same conditions where `end` is emitted. Emitted after
		`'end'`.
		- `finish` An end-ish event that follows the same logic as `end` and is
		emitted in the same conditions where `end` is emitted. Emitted after
		`'prefinish'`.
		- `close` An indication that an underlying resource has been released.
		Minipass does not emit this event, but will defer it until after `end`
		has been emitted, since it throws off some stream libraries otherwise.
		- `drain` Emitted when the internal buffer empties, and it is again
		suitable to `write()` into the stream.
		- `readable` Emitted when data is buffered and ready to be read by a
		consumer.
		- `resume` Emitted when stream changes state from buffering to flowing
		mode. (Ie, when `resume` is called, `pipe` is called, or a `data` event
		listener is added.)
		- `data` Emitted when there's data to read. Argument is the data
		to read. This is never emitted while not flowing. If a listener
		is attached, that will resume the stream.
		- `end` Emitted when there's no more data to read. This will be
		emitted immediately for empty streams when `end()` is called.
		If a listener is attached, and `end` was already emitted, then
		it will be emitted again. All listeners are removed when `end`
		is emitted.
		- `prefinish` An end-ish event that follows the same logic as
		`end` and is emitted in the same conditions where `end` is
		emitted. Emitted after `'end'`.
		- `finish` An end-ish event that follows the same logic as `end`
		and is emitted in the same conditions where `end` is emitted.
		Emitted after `'prefinish'`.
		- `close` An indication that an underlying resource has been
		released. Minipass does not emit this event, but will defer it
		until after `end` has been emitted, since it throws off some
		stream libraries otherwise.
		- `drain` Emitted when the internal buffer empties, and it is
		again suitable to `write()` into the stream.
		- `readable` Emitted when data is buffered and ready to be read
		by a consumer.
		- `resume` Emitted when stream changes state from buffering to
		flowing mode. (Ie, when `resume` is called, `pipe` is called,
		or a `data` event listener is added.)

		### Static Methods

		- `Minipass.isStream(stream)` Returns `true` if the argument is a stream,
		and false otherwise. To be considered a stream, the object must be
		either an instance of Minipass, or an EventEmitter that has either a
		`pipe()` method, or both `write()` and `end()` methods. (Pretty much any
		stream in node-land will return `true` for this.)
		- `Minipass.isStream(stream)` Returns `true` if the argument is a
		stream, and false otherwise. To be considered a stream, the
		object must be either an instance of Minipass, or an
		EventEmitter that has either a `pipe()` method, or both
		`write()` and `end()` methods. (Pretty much any stream in
		node-land will return `true` for this.)

		## EXAMPLES

		Here are some examples of things you can do with Minipass streams.
		Here are some examples of things you can do with Minipass
		streams.

		@@ -560,5 +588,5 @@ ### simple "are you done yet" promise

		This is a bit slower because it concatenates the data into one chunk for
		you, but if you're going to do it yourself anyway, it's convenient this
		way:
		This is a bit slower because it concatenates the data into one
		chunk for you, but if you're going to do it yourself anyway, it's
		convenient this way:

		@@ -574,13 +602,14 @@ ```js

		You can iterate over streams synchronously or asynchronously in platforms
		that support it.
		You can iterate over streams synchronously or asynchronously in
		platforms that support it.

		Synchronous iteration will end when the currently available data is
		consumed, even if the `end` event has not been reached. In string and
		buffer mode, the data is concatenated, so unless multiple writes are
		occurring in the same tick as the `read()`, sync iteration loops will
		generally only have a single iteration.
		Synchronous iteration will end when the currently available data
		is consumed, even if the `end` event has not been reached. In
		string and buffer mode, the data is concatenated, so unless
		multiple writes are occurring in the same tick as the `read()`,
		sync iteration loops will generally only have a single iteration.

		To consume chunks in this way exactly as they have been written, with no
		flattening, create the stream with the `{ objectMode: true }` option.
		To consume chunks in this way exactly as they have been written,
		with no flattening, create the stream with the `{ objectMode:
		true }` option.

		@@ -736,3 +765,3 @@ ```js
		chunk = Buffer.from(chunk, encoding).toString()
		} else if (Buffer.isBuffer(chunk))
		} else if (Buffer.isBuffer(chunk)) {
		chunk = chunk.toString()
		@@ -739,0 +768,0 @@ }

index.mjs

Sorry, the diff of this file is not supported yet

minipass - npm Package Compare versions

New alerts

Fixed alerts

Improved metrics

Worsened metrics