Restore support for package managers other than `npm`

[kirkwaiblinger]

In #180, support for pnpm/yarn was removed, for reasons that aren't super clear (I guess there was a bug with the support? #179).

I'd propose support for packing with pnpm/yarn be restored. If not via automatic detection, at least to the point of being able to specify a way to use attw in CI neatly. For example, while attw $(npm pack) is documented, and works fine, attw $(pnpm pack) fails, with:

error while checking file:
ENOENT: no such file or directory, open '📦'

[andrewbranch]

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.

[kirkwaiblinger]

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.

[kirkwaiblinger]

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)