You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
n watch <name> (per-project watch) does not work for a worktree-overridden plugin inside an isolated env. This is a known limitation, surfaced during review of #205 (the stacked fix for #188's global watch).
Background
In an isolated env (bin/env.sh), a --worktree <repo>:<branch> override is mounted at /newspack-plugins/<name> (overlaying the base ./plugins mount), while /newspack-monorepo is the base workspace checkout.
Before chore(n): harden global watch dispatcher and fix env path remap #205, bin/watch-repo.sh unconditionally remapped /newspack-plugins/<name> → /newspack-monorepo/plugins/<name>, so n watch <name> in an env silently watched the base (main) branch instead of the worktree under test.
chore(n): harden global watch dispatcher and fix env path remap #205 added an -ef (same-inode) guard so the remap only fires when both paths are the same directory. This correctly stops the silent wrong-branch build — but it leaves watch pointed at /newspack-plugins/<name>, whose pnpm workspace symlinks (node_modules/newspack-scripts -> ../../../packages/scripts) escape the single-subdir mount, so wp-scripts doesn't resolve and the watch toolchain hard-fails.
Net: #205 converts a silent wrong-branch build into a correct build / honest failure — an improvement — but watching a worktree-overridden plugin in an env still doesn't actually run.
Proposed approach (from review)
When the base /newspack-monorepo/{plugins,themes,repos}/<name> remap fails the -ef check (i.e. we're looking at a worktree override), resolve the override's branch-under-test under the monorepo mount instead:
/newspack-monorepo/worktrees/<safe_branch>/{plugins,themes}/<name> is the same host directory as the /newspack-plugins/<name> override (verifiable via -ef) and lives under /newspack-monorepo, so the worktree's relative pnpm symlinks resolve.
cd there and run npm run watch.
Open question / dependency
This only fully works if the worktree has its deps installed — bin/worktree.sh add does not run pnpm install, so a fresh worktree's node_modules/.bin/wp-scripts won't exist even at the resolvable path. The fix likely needs to either ensure deps are installed in the worktree or detect-and-message when they aren't.
Summary
n watch <name>(per-project watch) does not work for a worktree-overridden plugin inside an isolated env. This is a known limitation, surfaced during review of #205 (the stacked fix for #188's global watch).Background
In an isolated env (
bin/env.sh), a--worktree <repo>:<branch>override is mounted at/newspack-plugins/<name>(overlaying the base./pluginsmount), while/newspack-monorepois the base workspace checkout.bin/watch-repo.shunconditionally remapped/newspack-plugins/<name>→/newspack-monorepo/plugins/<name>, son watch <name>in an env silently watched the base (main) branch instead of the worktree under test.-ef(same-inode) guard so the remap only fires when both paths are the same directory. This correctly stops the silent wrong-branch build — but it leaves watch pointed at/newspack-plugins/<name>, whose pnpm workspace symlinks (node_modules/newspack-scripts -> ../../../packages/scripts) escape the single-subdir mount, sowp-scriptsdoesn't resolve and the watch toolchain hard-fails.Net: #205 converts a silent wrong-branch build into a correct build / honest failure — an improvement — but watching a worktree-overridden plugin in an env still doesn't actually run.
Proposed approach (from review)
When the base
/newspack-monorepo/{plugins,themes,repos}/<name>remap fails the-efcheck (i.e. we're looking at a worktree override), resolve the override's branch-under-test under the monorepo mount instead:/newspack-monorepo/worktrees/<safe_branch>/{plugins,themes}/<name>is the same host directory as the/newspack-plugins/<name>override (verifiable via-ef) and lives under/newspack-monorepo, so the worktree's relative pnpm symlinks resolve.cdthere and runnpm run watch.Open question / dependency
This only fully works if the worktree has its deps installed —
bin/worktree.sh adddoes not runpnpm install, so a fresh worktree'snode_modules/.bin/wp-scriptswon't exist even at the resolvable path. The fix likely needs to either ensure deps are installed in the worktree or detect-and-message when they aren't.References
n watch(base feature)-efguard that scopes the remap (this issue is the documented follow-up)