Blob.stream() per specification has no parameters

[guest271314]

What is the type of issue?

No response

What is the issue?

Blob.stream() per specification has no parameters https://w3c.github.io/FileAPI/#dom-blob-stream.

From the linked MDN entry

Syntax

stream()
Parameters
None.

A number is being passed to Blob.stream() in Bun documentation

const buf = Buffer.from("hello world");
const blob = new Blob([buf]);

// set chunk size of 1024 bytes
const stream = blob.stream(1024);

Where did you find it?

https://bun.sh/guides/binary/buffer-to-readablestream

[Jarred-Sumner]

This is used by Bun.file to specify chunk sizes

[guest271314]

That's not documented anywhere is not not in consistent with the linked MDN article nor the controlling W3C File API specification.

Additionally nowhere is it documented the Bun.stdin.stream() and Bun.file("/dev/stdin").stream() are not the same, behave differently #11712, .

[guest271314]

This is used by Bun.file to specify chunk sizes

That doesn't work anyway.

readable = Bun.stdin.stream(1048576);

will always read only 983036 bytes #11553.

[guest271314]

This stream will never read to 1048576

//  Presumably this is a `BunFile`, not a `Blob` stream
readable = Bun.file(0).stream(1048576);
// ...
   if (buffer.byteLength === 983036) {
      yield encodeMessage(`We can always catch: ${buffer.byteLength} ${buffer.maxByteLength} ${messageLength} ${reads++}`);
    }

[jimmywarting]

I agree that this is bad. it's like node's Buffer.slice() problem all over again.
one dose not mess with web spec. it's the biggest downfall of the old prototypejs when it messed with built in Object / functions

the proper way to solve this would be to do something like

blob.stream().pipeTo(new ChunkSizeStream( ... ))
// or 
blob.stream().getReader({ mode: 'byob' })

Messing with native built-in prototypes in JavaScript is generally considered bad practice for several reasons:

1. Breaks Assumptions of Other Code

• Many libraries and frameworks rely on JavaScript’s built-in prototypes (like Array.prototype, Object.prototype, etc.) behaving as expected.
• If you modify these prototypes, you might introduce unexpected behavior that breaks third-party code or even your own code in ways that are hard to debug.

2. Potential Naming Collisions

• If you add a method to a prototype (e.g., Array.prototype.myMethod), and later a new JavaScript standard introduces a method with the same name but different behavior, your code might break or behave inconsistently across different environments.

3. Hard to Debug

• Modifying prototypes affects all instances globally, making it difficult to trace unexpected behavior.
• Bugs might appear in unrelated parts of the codebase due to a seemingly innocent modification.

---

Exceptions (When It’s "Acceptable")

• Polyfills: Modifying prototypes can be acceptable when adding missing features to older JavaScript environments (e.g., adding Array.prototype.includes for older browsers).
• Well-Controlled Environments: If you are working in a fully controlled codebase (not using third-party libraries), and modifications are well-documented and understood by the team.

Instead of modifying built-in prototypes it's better to use utility functions or better or for worse extend blob

class BunFile extends Blob { 
  stream (chunkSize)  { ... } 
}

[jimmywarting]

if whatwg/fetch#1600 gets accepted and it somehow would extend onto Blob.stream() then you have shot yourself in the foot.