`fromStream()` tokenizers do not close the underlying Node.js `Readable`

[sindresorhus]

I found that strtok3.fromStream() tokenizers do not actually close the underlying Node.js Readable when tokenizer.close() is called.

Root cause:

• lib/core.js wires fromStream() through StreamReader
• lib/stream/StreamReader.js implements:
  • abort() as only this.reject(new AbortError())
  • close() as only return this.abort()
• Neither path calls stream.destroy()

So tokenizer.close() only aborts pending tokenizer reads. It does not tear down the source stream itself.

Why this matters:

A consumer can successfully detect enough bytes, call await tokenizer.close(), and still leave the original Readable and socket alive in the background. For HTTP responses, that means the body keeps downloading after the caller is done with detection.

I reproduced this with file-type, which correctly calls await tokenizer.close() in a finally block. Without a local workaround, a Node IncomingMessage stays open after detection completes.

Expected behavior:

await tokenizer.close() for tokenizers created from Node streams should close or destroy the underlying Readable, so consumers do not need package-specific teardown workarounds after successful detection.

[Borewit]

Hi Sindre,

The current behaviour of close() is that it releases the tokenizer’s access to the provided stream, whether that is a Node.js Readable or a Web ReadableStream, but it does not close, cancel, or destroy the underlying stream itself.

The original idea was that, since the stream is provided by the user, ownership remains with the user, who may want to continue using or manage the lifecycle of that stream independently.

That said, I agree this is confusing in practice. In most cases, users expect close() to fully clean up resources, including terminating the underlying stream. As described, the current behaviour can lead to unintended side effects, such as continued network activity after the tokenizer is no longer used.

A possible improvement would be to introduce a release() method that preserves the current behaviour, while changing close() to actively close, cancel, or destroy the underlying stream. This would align close() with common expectations, while still allowing advanced users to retain control when needed.

Do you agree with that approach?