[Mikola Lysenko (mikolalysenko)]

LLM Description written by Claude Code:claude-opus-5-5

Fixes #1629

This closes the variant #1680 left open: a yarn 1 global folder that yarn's
global-folder setting moved to a folder not named global.

Summary

yarn global add writes a package.json and yarn.lock into its global
folder. When global-folder moves that folder (for example
YARN_GLOBAL_FOLDER=/opt/yarn-g), it looks exactly like a small yarn 1
project on disk. socket-patch --update then refused with
yarn add @socketsecurity/socket-patch@latest. Run from the user's cwd,
that edits some other project and leaves the installed copy stale. It now
says yarn global add @socketsecurity/socket-patch@latest.

Root cause

update::channel::is_yarn_global_store recognized yarn's global folder
only by its default spelling (a global dir under a yarn home, or a
global dir holding yarn's lock). It never read yarn's config.

Fix

• patch::redirect::yarnrc::configured_yarn_global_folders lists every
  folder yarn 1 run in the cwd is configured to use as its global folder.
  It uses the same layers as the existing yarn-offline-mirror resolver,
  now shared through RcLayout: YARN_* / npm_config_* env, the cwd's,
  user's, prefix's and ancestors' .yarnrc (including a --global-folder
  default flag), and the same set of .npmrc files. Yarn uses only the
  first layer by precedence, but a folder that any layer names was set up
  as a yarn global folder, so every layer counts.
• Values decode the way yarn 1.22.22 decodes them. A .yarnrc value is one
  token of yarn's rc grammar: JSON double quotes, a bare word that ends at
  a space so a trailing # comment is dropped, and single quotes through
  the YAML fallback. It resolves against its file's folder. An .npmrc
  value goes through npm's ini decoding (quotes, ;/# comments,
  escapes) and yarn's envReplace (${NAME}; an unset name drops the
  value, as yarn fails to load it). Env and .npmrc values then go through
  resolveWithHome: ~/ is yarn's user home (/usr/local/share as root),
  and anything else resolves against the cwd.
• ChannelEnv carries the canonicalized folders. It reads them lazily, on
  first use, so only a yarn-owned node_modules install walks the rc files.
  upgrade_hint_for and channel_label_for take the ChannelEnv, and the
  two CLI call sites pass the one they already build.

I checked every decoding rule in the tests against a real yarn 1.22.22
(yarn global dir).

Not changed (reviewed)

• A --global-folder passed only on the command line at install time
  leaves no trace in config, so it can't be told apart from a yarn project.
  Such installs still get yarn add.
• The yarn-offline-mirror reader keeps its existing value parsing. The new
  token reader is used only for global-folder, so this PR doesn't change
  mirror behavior.
• /code-review high suggested moving the yarn 1 config resolver out of
  patch/redirect into a shared module. I kept it next to the mirror
  resolver whose file layout it reuses. Moving it is a separate refactor.
• The npm/PyPI/gem wrappers only dispatch the binary and have no update
  hint logic.

Tests (red → green)

Case	Test	Before	After
#1629: YARN_GLOBAL_FOLDER / yarn_global_folder / npm_config_global_folder, ~/.yarnrc, ~/.npmrc	update::self_update_channels_e2e::yarn_configured_global_folder_refuses_with_yarn_global_hint	fail (yarn add …)	pass
channel classification (nested copy, no lock yet, other projects unaffected)	update::channel::tests::yarn_configured_global_folder_gets_yarn_global_add	n/a (new API)	pass
config layers	yarnrc::tests::global_folder_layers_match_yarn	n/a	pass
path resolution (rc folder, cwd, ~/, root)	yarnrc::tests::global_folder_paths_resolve_like_yarn	n/a	pass
value decoding (--global-folder, comments, JSON/YAML quotes, ${NAME}, ini)	yarnrc::tests::global_folder_values_read_like_yarn	n/a	pass

Local: cargo fmt --all -- --check and cargo clippy --workspace --all-features -- -D warnings are clean, and cargo test -p socket-patch-cli --all-features --test update passes (68/68). cargo test -p socket-patch-core --all-features --lib passes 6704/6708. The 4 failures are permission-denied tests that fail the same way on main in this sandbox, which runs as root so chmod can't make writes fail: copy_tree, vlt_heal, pypi_poetry, pypi_requirements. cargo test -p socket-patch-cli --all-features --lib passes (933/933). The full cargo test --workspace --all-features build needs more disk than this sandbox allows (it ran out twice), so CI runs the rest of the integration suites.

/code-review high ran on the diff. Its findings are fixed in the second commit, except the module move listed under "Not changed".

https://claude.ai/code/session_01MFXsCQpS1bvSPpbaoq45V6

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 9e104c4. Configure here.}

[Mikola Lysenko (mikolalysenko)]

Ready for review at head 9e104c4.

• CI: all checks settled green on the current head (36 success, 50 path-skipped, none failing).
• Bugbot: reviewed 9e104c4, no findings; no open review threads.
• Doesn't touch CHANGELOG.md. Mergeable against main.
• Worth a look: the yarn global-folder detection in crates/socket-patch-core/src/patch/redirect/yarnrc.rs and how update / the update notifier pick the install channel from it.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Burn-down agent: labeled Ready for review.

• Head: 9e104c49c74bca4cb6a2071da5f1aa21021abf83
• CI: all check runs on this head green (none failing, no main-wide failures)
• Mergeable, no conflicts; does not touch CHANGELOG.md
• Bugbot reviewed this exact head: no findings; no open review threads
• Reviewer focus: the yarnrc/npmrc redirect changes and the self-update channel handling in update.rs/update/channel.rs.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Final review brief

What it does: socket-patch --update on a yarn 1 global install whose folder was moved by yarn's global-folder setting (e.g. YARN_GLOBAL_FOLDER=/opt/yarn-g) used to say yarn add …, because that folder looks like a yarn project. Run from the user's cwd, that edits some unrelated project. It now reads yarn's global-folder config (env, .yarnrc incl. --global-folder, .npmrc) and says yarn global add …. The rc-file layout code moves into a shared RcLayout. Mirror resolution behaves as before.

Risk: low–medium. It only changes the hint/label for yarn-owned node_modules installs, and config is read lazily, so other channels never walk rc files. The rc reading is read-only path comparison (no exec). The new parsers (yarnrc_token, ini_value, yarn_env_replace) have the most edge cases, but a misparse only falls back to the old yarn add hint.

Look here:

• yarnrc.rs:393: configured_yarn_global_folders (which layers count, and how each value resolves)
• yarnrc.rs:447-560:`` token, ini and ${NAME} decoding
• channel.rs:82: lazy OnceLock read + canonicalize
• channel.rs:317 / channel.rs:331: the lock check now comes before the config lookup, and the configured folder is matched against the outermost node_modules holder
• self_update_channels_e2e.rs:221:``` end-to-end refusal hint for env, ~/.yarnrc and `~/.npmrc`, plus the unconfigured control case

Verified: I read the full diff. Locally, cargo test -p socket-patch-core --all-features --lib -- global_folder yarn_configured_global passes 4/4. The update notifier only builds the hint once a newer release is found, so there's no extra rc I/O on normal runs. CI on the head is green: ci-ok ✅, clippy ✅, Cursor Bugbot ✅. No review threads. CHANGELOG.md untouched.

Changes I made: none.

Open questions: none blocking. The description notes that moving the yarn 1 config resolver out of patch/redirect was deferred as a separate refactor.

Auto-merge is armed, so approving sends it straight to the merge queue.

---

Generated by Claude Code