feat(streams): add `Base64EncoderStream` and `Base64DecoderStream`

[babiabeo]

Close: #3087

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 92.85714% with 5 lines in your changes are missing coverage. Please review.

Project coverage is 91.89%. Comparing base (377043c) to head (7aa7e50).

Files	Patch %	Lines
streams/base64_decoder_stream.ts	84.84%	5 Missing :warning:

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4756      +/-   ##
==========================================
- Coverage   91.89%   91.89%   -0.01%     
==========================================
  Files         485      488       +3     
  Lines       41308    41391      +83     
  Branches     5317     5321       +4     
==========================================
+ Hits        37959    38035      +76     
- Misses       3292     3299       +7     
  Partials       57       57              

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[babiabeo]

As suggested by @BlackAsLight, I have removed line breaks handling from both encoder and decoder.

[kt3k]

As suggested by @BlackAsLight, I have removed line breaks handling from both encoder and decoder.

I think this also works. In this case, we can remove/insert line-breaks before/after the decoding/encoding.

[kt3k]

I wonder if it makes more sense to put these APIs next to the encodeBase64/decodeBase64 APIs in @std/encoding/base64. WDYT? cc @iuioiua @crowlKats

[iuioiua]

I wonder if it makes more sense to put these APIs next to the encodeBase64/decodeBase64 APIs in @std/encoding/base64. WDYT? cc @iuioiua @crowlKats

Yep.

[iuioiua]

Before merging this in, I'd like to know more about any justifications for encoding/decoding streams. Adding these APIs will likely set a precedent for other streaming modes like base 32, etc.

[kt3k]

I'd like to know more about any justifications for encoding/decoding streams.

It's used for encoding/decoding a huge data, the size of which exceeds the memory limit of your program.

[iuioiua]

We recently agreed to not have encoding/decoding + streaming APIs in the Standard Library as we thought there aren't many use cases. Perhaps, we were wrong. If we say yes to this API, we should say yes to the rest.

[kt3k]

We recently agreed to not have encoding/decoding + streaming APIs in the Standard Library as we thought there aren't many use cases.

Can you link to the discussion?

[iuioiua]

The agreement was made in a previous weekly deno_std meeting. I sent you the details.

To be clear, I'm happy with having Base64EncoderStream in the Standard Library; we should be aware that doing so will set a precedent and justify having the others in there, too. And at that point, maybe we should just include @doctor/encoding-stream in the Standard Library (with permission from and proper attribution for @BlackAsLight, of course).

[BlackAsLight]

And at that point, maybe we should just include @doctor/encoding-stream in the Standard Library (with permission from and proper attribution for @BlackAsLight, of course).

Sure

[babiabeo]

If encoding/decoding + streaming APIs are allowed in the Standard Library, should we create a new PR for all stream encoders/decoders and close this PR? This PR only implements the base64 encoder and decoder based on mazira/base64-stream which may not be the same as @doctor/encoding-stream/base64.

[BlackAsLight]

This PR only implements the base64 encoder and decoder based on mazira/base64-stream which may not be the same as @doctor/encoding-stream/base64.

Your implementation is more or less the same as mine. I would characterise mine as more tidy though.

[iuioiua]

Yes, let's close this PR and open a new one, adding @doctor/encoding-stream to std/encoding in new files. I.e., encoding/base32_stream.ts, etc.