Superceded by tar-stream?

[fresheneesz]

It looks to me like tar-stream has more functionality, generatlity, and a better API. Should work be done on node-tar when another package covers all that ground better than this one does?

[othiym23]

npm uses node-tar, and has specific edge cases that specifically depend on node-tar's specific traits. Until we have the time to ensure that the move to tar-stream doesn't break npm, and shepherd through any necessary changes to tar-stream to get the specific edge cases we need handled (mostly around extended attributes and platform differences), npm will continue to use node-tar.

[fresheneesz]

@othiym23 Fair enough, but can we leave this issue open to record that we may want to go through that process?

[rlidwka]

As far as I know, npm is able to install from any tarball, and any modern tar implementation should unpack npm tarballs. So what edge cases are there?

According to the benchmarks, it's also 10 times faster. I'd say it's reason enough to switch, especially because unpacking could be the slowest part of the install.

[edef1c]

@rlidwka That's an underestimation of the weird edge cases node-tar handles. We don't use tar(1) even if it's available for the same reasons.

[othiym23]

Extended attributes, custom headers, ACLs – if you've ever heard @isaacs talk about the time he put into getting node-tar right, you know that it was a major labor of passion for him. I really can't see npm switching without there being some kind of conformance suite we can put both tar-stream and node-tar through to compare how they handle weird situations on all of the OSes that npm supports.

[fresheneesz]

I would imagine node-tar's tests might be such a conformance suite? Then again, I have no concept of how much isaacs believes in unit-testing.