Can no longer set encoding on `t.list` stream.

[wraithgar]

With the update to minipass 7, setEncoding is now required to be done during instantiation.

It does not appear that this is possible anymore, at least with list as the instantiation for fs-minipass is static

[isaacs]

Yeah, setEncoding can only be done at instantiation, because otherwise it runs afoul of TS's limited run-time variadic type support.

But the code you reference here is the bit where it's reading the file to be parsed, not sure why you'd ever want that to not be binary, since the parser is parsing tar, which is a binary format. (Or gzipped tar, which is even more binary lol.)

Do you intend to set the encoding on the entry streams emitted by the t.list() parser? If so, yeah, I don't think there's a way to do that, since the ReadEntry is created deep in the guts of the parser. It seems like an oversight to not have a way to pass in an encoding option to the parser for that purpose, which would then be used for any file entries in the archive.

[wraithgar]

Do you intend to set the encoding on the entry streams emitted by the t.list() parser?

Yes. I made a very lazy effort to track down what I was seeing, sorry.

Here's the use case we have. (Running perfectly w/o need for change since the initial implementation, shoutout to Ruy).

[isaacs]

Does it work if you change this bit:

          entry.setEncoding('utf8')
          content = entry.concat()

to this?

          content = entry.concat().then(b => b.toString('utf8'))

I still think it's an oversight, and that parse should take a encoding option, but that might work right now without having to wait for a release.

[isaacs]

Oh, I see why it got lost in the transition to typescript.

Setting the encoding is actually quite a huge pain, because the variadic type has to be threaded all the way through.

So, for example, there needs to be three signatures for the Parser class, depending on whether the encoding option passed in was null or missing (Parser<Buffer>), or an encoding option (Parser<string>), or unknown at compile time (Parser<string | Buffer>). Then that same encoding option and variadic type dependency has to be passed through everywhere that ReadEntry appears, which is a lot of places, since that's also the signature of the onReadEntry, various event handlers, all the piping, etc. Since you can provide an onReadEntry method as an option, that also means that the TarOptions type has to carry that info along with it. And, at all points along this, everything has to match and be kept in sync.

So yeah, the solution here is just to deal with the fact that it's giving you buffer objects. Having streams that can emit either Buffers or Strings (or any object!) based on run-time settings is a regrettable mistake in hindsight.