chore: upgrade to Yarn 4

[iskounen]

Upgrades this repo from Yarn 1 (classic) to Yarn 4 (Berry). This is the proper fix for the CI failures introduced in #76 — every attempt to invoke Yarn 1 in a Corepack-enabled environment routed back to the globally installed Yarn 4, making compatibility workarounds unworkable.

Changes:

• package.json: updated packageManager to yarn@4.17.0
• yarn.lock: regenerated in Berry format
• .yarnrc.yml: new Yarn 4 config file (nodeLinker: node-modules, enableGlobalCache: true)
• .gitignore: ignore .yarn/install-state.gz
• setup-and-install action: removed all Yarn version detection and workaround code — now just yarn install --immutable
• claude-review.yml: updated --frozen-lockfile to --immutable

🤖 Generated with Claude Code

[github-actions]

Detected new or modified files in .github/workflows/. Please ensure you update the relevant documentation alongside these workflow changes.

[claude]

Code Review

Summary
This PR upgrades the duchamp repo from Yarn 1 (Classic) to Yarn 4 (Berry): bumps packageManager to yarn@4.17.0, adds .yarnrc.yml (nodeLinker: node-modules, global cache), regenerates yarn.lock into Berry v10 format, switches all CI install steps from --frozen-lockfile to --immutable, updates the cache path, and simplifies the setup-and-install action by dropping Yarn-version auto-detection. The mechanical parts are consistent and correct.

Issues Found

🟡 Important — setup-and-install drops Yarn 1 support (shared action)
.github/actions/setup-and-install/action.yml:39 now hardcodes yarn install --immutable, removing the branch that handled Yarn 1 (--frozen-lockfile) vs Berry. This action is reused by other repos via danger.yml (install-from-caller: true), where it installs against the caller's workspace. --immutable is Berry-only, so any consumer still on yarn@1.x will lose the immutability guarantee or fail. Likely intentional given the upgrade, but it's a breaking change for shared tooling worth confirming. (See inline comment.)

Areas Reviewed

• Architecture & Design — duchamp's .yarnrc.yml (enableGlobalCache: true) only governs duchamp's own installs; caller repos using install-from-caller: true keep their own Yarn config, so the actions/cache path ~/.yarn/berry/cache will only hit for callers that also enable the global cache. Not a failure — just reduced cache effectiveness for some callers.
• Consistency — Verified all install invocations were updated: tests.yml, claude-review.yml (x2), and the composite action all use --immutable; no --frozen-lockfile or ~/.cache/yarn/v6 references remain. tests.yml correctly adds corepack install. .gitignore correctly adds .yarn/install-state.gz for the node-modules linker. OK
• Lockfile — yarn.lock is correctly regenerated to Berry format (__metadata: version: 10). OK
• Security — No concerns. enableScripts: true matches Yarn's default (lifecycle scripts already ran under Yarn 1), so it is not a new risk; redundant but harmless.

Questions for Author

1. Are all repos that consume the danger/setup-and-install reusable workflows already on Yarn Berry? If any remain on Yarn 1, the --immutable switch and the ~/.yarn/berry/cache path will break them.
2. Minor: enableScripts: true in .yarnrc.yml is already Yarn's default — intentional for explicitness, or leftover?

[claude]

🟡 Removing Yarn-version detection may break Yarn 1 caller repos.

This composite action is consumed by other repos through danger.yml (uses: ./.tooling/.github/actions/setup-and-install with install-from-caller: true), where the install runs against the caller's workspace — not duchamp's. The old logic deliberately branched on the caller's packageManager/yarn --version and used --frozen-lockfile for Yarn 1 and --no-immutable for Berry.

--immutable is a Yarn Berry–only flag; Yarn 1 (yarn@1.x) doesn't support it. With corepack enabled, a caller repo still on packageManager: yarn@1.x will invoke Yarn Classic with --immutable, which at best ignores the flag (losing the immutability guarantee) and at worst errors out. The same applies to the cache path change above (~/.yarn/berry/cache is Berry's global cache; Yarn 1 uses ~/.cache/yarn).

If all consumer repos are already on Yarn Berry, this is fine and the simplification is good — but that's an assumption worth confirming, since it's a breaking change for shared tooling. Could you confirm no consumer repo still uses Yarn 1?

[iskounen]

Checked all duchamp consumers by:

1. Finding all repos that reference duchamp

gh search code 'artsy/duchamp' --owner artsy --extension yml

2. Checking the Yarn version in each repo's package.json.

for repo in eigen force gravity energy doppler volt metaphysics fresnel palette positron artsy.github.io; do
  result=$(gh api repos/artsy/$repo/contents/package.json --jq '.content' 2>/dev/null | base64 -d 2>/dev/null | grep '"packageManager"' | head -1)
  echo "$repo: ${result:-no packageManager field}"
done

The only repo using install-from-caller: true is metaphysics, which is already on Yarn 4.17.0, so no breakage there.

https://github.com/search?q=org%3Aartsy+install-from-caller&type=code

The three repos still on Yarn 1 (fresnel, palette, positron) all use danger-yarn.yml, but that workflow doesn't pass install-from-caller, so it defaults to false, meaning it installs from .tooling (duchamp's own Yarn 4 deps), never touching the caller's lockfile.