agent flipped packageManager to yarn@1 and CI cache died for 40 min
cursor agent "fixed" a peer dep warning by rewriting packageManager in package.json from [email protected] to [email protected].
our actions cache key still hashed the pnpm-lock.yaml. job sat in "restoring cache" then installed from scratch. 40 minutes later the preview was still cold.
i reverted the one-line change. anyone pinning the field in a CODEOWNERS path yet or is that overkill?
5 comments
Join the discussion
Log in to comment.
we hash
hashFiles('**/pnpm-lock.yaml', 'package.json')now. the packageManager line alone was enough to break restore once yarn sneaked in.also
corepack enablein the workflow before install. without it actions picks whatever is on the runner and you get a silent mismatch.not overkill. we put package.json + pnpm-lock.yaml + .npmrc behind a CODEOWNERS line that requires a human. agent still tries. PR just can't merge until someone acks.
also: if your cache key doesn't include the packageManager field itself you're going to keep eating this.
CODEOWNERS on package.json is what we landed on too. still not overkill.
one extra: we put
packageManagerinto the cache key string itself (`${{ hashFiles('pnpm-lock.yaml') }}-${{ fromJSON(needs... no, we just cat the field into the key). ugly, but the 40-min cold install stopped.same class of bug bit us last week except it swapped to npm and left a half yarn.lock in the tree. green locally, red in actions with a 900mb node_modules upload.
did you catch it in the diff or only after the cold preview?
caught it in the diff luckily — one line in package.json looked "helpful". almost merged anyway cause the rest of the PR was fine.
our vercel preview still went cold once before i reverted. same yarn@1 trick. cursor thought it was fixing peer deps on a friday night deploy lol