Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Additional tar compatibility #14

Open
1 task
benmccann opened this issue Aug 28, 2024 · 2 comments
Open
1 task

Additional tar compatibility #14

benmccann opened this issue Aug 28, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@benmccann
Copy link

Describe the feature

There are a group of folks from https://e18e.dev that are going around the ecosystem and swapping out heavy libraries for lighter ones. It seems like it'd be great to switch some libraries to use nanotar to reduce their dependencies. However, the two APIs are fairly different making it somewhat difficult to do it in a bunch of places and get people to quickly adopt nanotar.

E.g. the first instance I went to look at was tar.extract({ file: tarball, cwd: to, strip: 1, onentry: filter_func }) and it's not super obvious how to swap it for nanotar.parseTar(data).

A few things that might help here to accelerate that:

Additional information

  • Would you be willing to help implement this feature?
@benmccann benmccann added the enhancement New feature or request label Aug 28, 2024
@ayuhito
Copy link

ayuhito commented Aug 29, 2024

For additional reference, we're talking about replacing tar. tar-fs, but also gunzip-maybe in the process which have a lot of dependencies.

I have a branch to replace it in @remix-run/dev and create-remix. It's still incomplete, but it's a little bit of a heavy-handed migration.

Though I understand the APIs are completely different so it naturally won't be easy to migrate.

@pi0
Copy link
Member

pi0 commented Aug 29, 2024

Hi, and thanks for your interest in this project.

If you have suggestions to make API of nanotar more DX friendly (without adding to it's complexity, bundle size hugely and runtime dependency) please feel free to open discussions i am certainly willing to hear them 👍🏼

Depending on runtime-specific APIs and mimicking the bigger alternatives is not a goal of this project. (otherwise we will eventually be them). What I would suggest, is that you might find it useful to make a wrapper library that adds functionalities such as file-system support by export conditions to make it a more obvious replacement for tar/tar-fs.

(i have some future plans re fs support but it can take time)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants