Revamp

[jimmywarting]

v3.0.0

• Changed WeakMap for private field (require node 12)
• Switch to ESM
• blob.stream() return a subset of whatwg stream which is the async iterable
  (it no longer return a node stream - now it returns a AsyncGenerator)
  • If you really want to have a node stream then you would have to use Readable.from(blob.stream())
• Reduced the dependency of Buffer by changing to global TextEncoder/Decoder (require node 11)
• Disabled xo for index.js since it could not understand private fields (#)
• No longer transform the type to lowercase (Implementations allow all values in type getter w3c/FileAPI#43)
  This is more loose than strict, keys should be lowercased, but values should not?
  It would require a more proper mime type parser - so I just made it loose.
• index.js can now be imported by browser & deno from a CDN since it no longer depends on any
  core node features and dose not bundle anything to commonjs
• used a more direct approach to convert blob to string that don't involve allocating hole arrayBuffer that would take up twice as much RAM while converting it to a string
• changed node engine to just be >12+ in package.json

closes #51 #53 #67 #62

[codecov]

Codecov Report

Merging #83 (a0c0abe) into master (a8fed4e) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            master       #83   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            2         2           
  Lines          238       289   +51     
  Branches        40        44    +4     
=========================================
+ Hits           238       289   +51     

Impacted Files	Coverage Δ
from.js	100.00% <100.00%> (ø)
index.js	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a8fed4e...a0c0abe. Read the comment docs.

[jimmywarting]

Change CI node version to something higher?

[tinovyatkin]

👍🏻 cool stuff!

[jimmywarting]

Only remaning question now is:
What to do with workflows/ci.yml to make the test pass? Probably have to change engine in package.json to something higher also... what is the lowest node support for ESM?

[tinovyatkin]

What to do with workflows/ci.yml to make the test pass? Probably have to change engine in package.json to something higher also... what is the lowest node support for ESM?

It was unflagged in 13.x release, then backported into 12.x. I would put something like 12.13 - the release when 12.x becomes LTS

[jimmywarting]

Would like to publish this to npm as 3.0.0-rc.0 and begin to roll it out for testing.

But wondering first a bit about #51 so we don't do any more breaking changes...

• I'm still in favor of the partial support of the whatwg blob.stream() as a async generator rather than having no stream() method at all. And leaving this PR as is.
• I would like for it to be isomorphic, So you can call for await (const chunk of blob.stream()) { ... } no mather what kind of stream/iterator it is.
• I do not wish to import the hole whatwg stream polyfill just for a spec compatible readable stream - simply to much IMO
  • it don't fit so well suited in the Node ecosystem to use whatwg stream in Node since it's not natively supported, but i hope it will one day
  • I have tried to worked with both native streams in browser and the polyfilled stream package in harmony but it's a bit of pain when you can't pipe a native readable stream to polyfilled writable stream since they are not the same instances so it don't work that well together
• We strive towards being spec compatible and having a Node-stream or a async generator is a different behavior. So is having a different none standard name like blob.toAsyncIterator() that later have to be depricated once/if Node decide to add whatwg streams. Other users also need to learn and adopt to "known differences between other blobs" rather then doing something none isomorphic
  • I don't feel like we have had much complain/comments/discussion about having a none-standard node-readable stream() (only from one person?) before for as long as fetch-blob have existed.
• I know NodeJS have some talks around supporting iterators more in some bits an places like writing a iterator directly to a file fs.write(path, blob.stream()) <-- our generator that yields uint8array - so keeping it as a asyncIterator is of interest to me if it can write a blob to the disk without any whatwg or node stream involment. node-fetch is also striving towards this path of supporting iterators instead of dealing with what kind of stream it's

ofc, you could iterate over a blob by slicing 'n reading blob.slice(x, y).arrayBuffer() yourself. but this feels like a #developer-pain

I think this can be easily subclassed/upgraded in user-land by either upgrading our Blob.stream() iterator/generator into a spec compatible whatwg stream if they need it. Or polyfiling browsers ReadableStream iterator so for-await-of can be used everywhere. see #51 (comment) for more discussion/solution about this.
I think that if someone decides to use fetch-blob then they should know what they are in for in regards to known differences about the stream method in the readme.md and also for some way(s) to solve this different behavior in the stream() method if they need it - at the same time i think it's good to do as much as possible to make it's as isomorphic a possible by having a async generator then having no stream() method at all so it can work in as many places as possible but it could also be bad if it return something none spec compatible

Would have been nice if the blob spec had @@symbol.asyncIterator so for await (let chunk of blob) works (spec proposal maybe? feels a bit redundant when you can get hold of the iterator by simply calling stream()) Browsers ReadableStream iterator isn't implemented anywhere yet - but it can be polyfilled

Would like to hear someones else opinion also - don't want this to be one sided. Do someone else agree with me or do you think it's bad to have a none spec generator instead of a whatwg stream with symbol.asyncIterator?
In other words is it better to have no stream method so user have to do the slice 'n read instead? Maybe should take up this discussion in #51

Some folks already depend on our blob#stream() method and it would be even more breaking to remove it entirely then what it already is by downgrading our node-stream into a generator function and making it dependency-free from nodejs

[xxczaki]

@jimmywarting

Do someone else agree with me or do you think it's bad to have a none spec generator instead of a whatwg stream with symbol.asyncIterator?

I vehemently agree with you - until there is no official & stable WHATWG stream support in Node.js, it's best to do the isomorphic approach with AsyncGenerator.

(...) discussion in #51

I read the discussion. If we want to make fetch-blob web-compatible (and therefore not take the node-fetch) approach), we can do what the issue author suggested.

Some folks already depend on our blob#stream() method and it would be even more breaking to remove it entirely then what it already is by downgrading our node-stream into a generator function and making it dependency-free from nodejs

👍

[xxczaki]

Great job.

done

[jimmywarting]

will release 3.0.0-rc.0 tomorrow if there are no objections, never good to do release durning the night