Challenges with `bun` vs. `npm`

[dwhswenson]

Using bun install --frozen-lockfile to build astro sites here, when I'm using npm locally, is more of an annoyance than I expected.

It boils down to oven-sh/bun#4899. The issue is that a dependency of jest is using a fork of cliui which uses aliasing in a way that apparently bun can't handle (although only in CI, it seems?) when npm writes the package-lock.json. Here's the offending dependency tree:

└─┬ jest@30.0.5
  └─┬ @jest/core@30.0.5
    └─┬ @jest/reporters@30.0.5
      └─┬ glob@10.4.5
        └─┬ jackspeak@3.4.3
          └── @isaacs/cliui@8.0.2

The @isaacs/cliui dependency does some dependency renaming in order to have two versions of a few dependencies around.

I've come up with several ways we might solve this, and I'm open to other options as well.

1. Only install production dependencies. I think it is safe to bet that anyone building their site in the context of this action only needs production dependencies. And it is likely that most people who hit this would be getting this exact issue, which comes from jest. This just requires adding a -p flag to the bun command. The obvious downside is that this doesn't solve all potential problems, just the one that I ran into.
2. Try to install from frozen lockfile, but do a normal install if that fails. I don't love this, because it kind of breaks the whole point of the lockfile, but bun install --frozen-lockfile || bun install would probably do the trick.
3. Drop bun; use npm. Seems like a pretty easy option as well, and although I get that there are practical benefits to bun, for the kind of projects we're probably looking at, how important are they?
4. Make it the user's problem to solve. Also not a fan of this. I may have something that I think gets me through the install issues, but now I'm having problems later. I can't tell if that's a node version thing, but that may be another issue.

@ethanholz : This was your addition, and I think you're more plugged into the TypeScript/JavaScript sphere than I am. What's the best approach here?

[ethanholz]

I think going with option 1 is probably our best option in here but supporting multiple options in the future is probably the way to go (including overrides and specializing other package managers). We will get this updated this week.

[ethanholz]

This isn't complete. But we have addressed one of the issues here for immediate usage.

[ethanholz]

I want to use this as inspiration when working with JS/TS projects. This would basically allow for us to auto-detect the lockfile if it exists (or a user can override it) and then install that package manager for installing dependencies.