Ship a Yarn Berry lockfile: the classic lockfile breaks from-source git installs

[navarrotech]

Problem

@jalapenolabs/cli is consumed straight from git (not npm), so a downstream Yarn Berry project builds it from source on install. The repo ships a Yarn Classic yarn.lock (no __metadata key), which forces Berry to bootstrap Yarn 1.22 to build the package:

Packing @jalapenolabs/cli@...from sources
Using Yarn Classic for bootstrap. Reason: "__metadata" key not found in yarn.lock, must be a Yarn classic lockfile

That nested Yarn Classic install then flakily corrupts its own tarball cache and fails extraction, aborting the whole install:

error .../undici-types-6.21.0.tgz: Extracting tar content of undefined failed, the file appears to be corrupt:
  "ENOENT: no such file or directory, chmod '.../undici-types/README.md'"
error Error: ENOENT: no such file or directory, open '.../emoji-regex/.yarn-tarball.tgz'
error .../signal-exit-4.1.0.tgz: Extracting tar content of undefined failed, the file appears to be corrupt

The failing file differs run to run (undici-types, emoji-regex, signal-exit), which points at the Yarn Classic extraction path, not any one dependency.

Impact

Any Berry consumer that installs cli from git in a clean environment (for example a node:24-slim Docker image with git + ca-certificates) cannot complete yarn install. Installs only succeed where a prior node_modules was seeded and persisted, which hides the break until a fresh build.

Repro

1. In a clean Yarn Berry project, add "@jalapenolabs/cli": "https://github.com/JalapenoLabs/cli.git".
2. yarn install in a clean container (no pre-existing cache/node_modules).
3. The from-source build bootstraps Yarn Classic and fails with the corrupt-tarball errors above.

Recommended fix

Migrate the repo to a Yarn Berry lockfile so consumers build it with Berry (no classic bootstrap):

• Adopt Yarn Berry (packageManager: "yarn@4.x", .yarnrc.yml with nodeLinker: node-modules), regenerate yarn.lock, and commit it. @jalapenolabs/uikit already builds cleanly this way.

Sibling to how downstream projects wire this dependency; happy to help validate the fix against a clean Docker build.