Restore support for package managers other than npm #274

Activity

1. andrewbranch commented on Jun 25, 2026

   

   andrewbranch

   on Jun 25, 2026

   Collaborator

   More actions

   The issue as I recall it was that there was no way to control the output path/name of the tarball, which would leave attw to have to hard-code the patterns from 3+ different package managers or parse their CLI output (both fragile to external changes) or I guess diff readdir() before and after and guess (also seems fragile and race-prone). That might not seem like a huge deal, but since --pack cleans up after itself, it needs to be 100% sure it can never run into a false positive where it deletes a file it didn't just produce. I think I held off on revisiting this because I decided it would be better just to import or reimplement a sufficiently good packing algorithm to be able to produce a tarball into a virtual file system or an OS tmp dir. I also eventually came to have second thoughts about the project's current stance of testing a packed tarball in isolation, after seeing a few examples of bugs that could only be caught with the real dependency graph present. Between those two things, it didn't feel worth it to pursue integration with other package managers.

   👍React with 👍2Reacted by Kirk Waiblinger and William jackson
2. kirkwaiblinger commented on Jun 29, 2026

   

   kirkwaiblinger

   on Jun 29, 2026

   ContributorAuthor

   More actions

   makes sense, thanks for the explanation!

   I think I held off on revisiting this because I decided it would be better just to import or reimplement a sufficiently good packing algorithm to be able to produce a tarball into a virtual file system or an OS tmp dir. I also eventually came to have second thoughts about the project's current stance of testing a packed tarball in isolation, after seeing a few examples of bugs that could only be caught with the real dependency graph present. Between those two things, it didn't feel worth it to pursue integration with other package managers.

   I guess these two things seem like a bit at odds? Implementing/importing a custom packing algorithm seems like it would minimize faithfulness to the actual published package, whereas making use of the resolved dependency graph seems like it maximally depends on the published package, effectively automating an integration test.

   But, either way, if package manager detection is not being reimplemented (a completely valid decision), this leaves me a bit unsure what the "recommended" way to use arethetypeswrong would be in the meantime... publish a temp version to npm and run arethetypeswrong against that? Or is attw <tarball-name> still the best approach to use in CI?

   For the purposes of resolving this issue, would it be best to recommend something roughly like this for general usage (replacing the attw $(npm pack), which only works with npm specifically)?

   To use `attw` in situations where the `--pack` option doesn't correctly produce the same tarball as you'd publish (for example, if you're using pnpm or yarn), you'll want to:
   
   1. create the custom tarball (via `pnpm pack`, `yarn pack`, or your custom build system)
   2. run `attw <tarball-name>`
   
   Tip - since the tarball's name may be difficult to predict (it usually incorporates the version of the package being packed), something like this should work in most situations:
   
   ```sh
   pnpm pack # or other pack command
   attw *.tgz 
   rm *.tgz # optional cleanup
   ```
   
   Customize this script as appropriate, especially if you happen to keep other `*.tgz` files in your directory.

   I'd be happy to open a docs PR to this effect.
3. kirkwaiblinger commented on Jun 29, 2026

   

   kirkwaiblinger

   on Jun 29, 2026

   ContributorAuthor

   More actions

   Oh, actually, I forgot that I already did a docs change in #275. That's probably sufficient to get the main point across (except for the helpful hint about just using shell expansion to deduce the tarball's name since you won't usually know it)

   👍React with 👍1Reacted by Andrew Branch