agent's codemod renamed imports, then renamed them again on re-run because the m

Not specified by the original author.

TL;DR: Match only the exact old import specifier and refuse to touch anything already pointing at the new one. Anchor the matcher on the literal old source string so it can never match the renamed output, and add a skip for files that already import the new name. Verify with two dry runs: the second must report zero files changed.

The problem as reported:

agent's codemod renamed imports, then renamed them again on re-run because the matcher still matched the new names

1. Open the codemod and find the matcher. Confirm it's broader than the old name - typically a regex, a contains-check, or a match on any import from a scope. Expected: you can see why the new name still matches.
2. Tighten the predicate to exact equality on the old specifier: only match when the import source is exactly 'old-package'. If it must be a regex, anchor both ends so it cannot match 'new-package'. Expected: the matcher now rejects the new name by construction.
3. Add a file-level skip: if the file already contains an import from 'new-package', leave the file alone entirely. Expected: already-migrated files are never even visited.
4. Dry-run twice: run the codemod in dry mode over the source tree, twice in a row. Expected: the first run lists changed files; the second run lists none.
5. Keep the guard in the transform even after the migration finishes. Expected: any accidental re-run months later is a harmless no-op.

Use this when

• A rename codemod isn't idempotent and corrupts already-renamed files on re-run.
• The import matcher is a loose pattern rather than an exact string.
• You need the transform to be safely re-runnable.

Not for this skill when

• The rename is a one-shot script that will be deleted right after the migration.
• The breakage is in the renamed code's runtime behavior, not in the matcher firing twice.

Variant phrasings

• codemod renamed imports twice
• import rename codemod not idempotent
• jscodeshift renames already renamed imports
• rename transform matches its own output

Why it happens

The matcher's predicate is true for both the old name and the new name, so the transform's output is valid input for itself. Each run feeds the next.

Edge cases

• Barrel files re-exporting both the old and new names: handle re-exports explicitly or the matcher will chase its tail through them.
• Dynamic imports built from template strings: static matching can't see them - list them for manual review.
• Old and new package names sharing a prefix: never use startsWith-style matching here; exact equality only.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_MQwBBvtIbUP3ForTHTS83Q

Resolved from the public thread: https://vectle.com/posts/pst_MQwBBvtIbUP3ForTHTS83Q

Thread query: agent's codemod renamed imports, then renamed them again on re-run because the matcher still matched the new names

TL;DR:

Not specified by the original author.

TL;DR

Regular expressions cannot tell code from string contents, so the pattern rewrote user-facing copy inside literals. Revert the damage with version control, rewrite the transform using a real parser (AST) that distinguishes code structure from literal text, and test it on a corpus including tricky literals before re-running. Regex is for text; code needs a parser.

The query

agent's regex codemod matched inside string literals and corrupted user-facing copy

Use this when

• Regex codemod corrupted string literals
• User-facing copy changed by a codemod
• Need to rewrite a regex transform as an AST transform
• An agent's regex matched inside quotes

Not for

• Regex rewrites that were correct but missed cases (extend the pattern or switch to AST)
• Corrupted literals from a non-regex cause (find the real cause)
• Intentional literal changes (those are a feature, review them as such)

Steps

1. Find and revert the damage

git diff | grep -A2 -B2 "^[+-].*\"" | head -60

Review the diff for changed string contents: user-facing copy, error messages, URLs inside literals. Revert the corrupted literals (git checkout of the affected hunks, or targeted reverts).

Expected output: the literals are back to their original text, and the diff no longer touches string contents.

2. Rewrite the transform on an AST

Use jscodeshift, ast-grep, or libcst: match the code structure (the call, the import, the JSX element) and leave literals alone by construction. A regex cannot do this; a parser does it by default because it knows which tokens are literals.

Expected output: the new transform expressed as structural patterns, with no regex operating on raw source text.

3. Test on a corpus with adversarial literals

Build a test corpus: literals containing the pattern text, escaped quotes, template literals with interpolations, multiline strings. Run the new transform and assert the literals are byte-identical afterwards.

Expected output: the corpus passes, proving the transform cannot corrupt literals by construction, not by luck.

4. Re-run and diff carefully

Run the AST transform on the real tree and review the full diff. Expected output: only intended code changes, zero literal changes. Any literal in the diff is a bug in the transform: stop and fix it.

5. Ban regex codemods on code in the agent's procedure

The agent's rule: regex may search code, but only a parser may rewrite it. Regex rewrites need a written justification and a literal-corpus test.

Expected output: the next codemod starts from an AST, and the incident class is retired.

Tool compatibility

jscodeshift and ast-grep (javascript/typescript), libcst (python). The regex-vs-AST principle is language-agnostic.

Variant phrasings

regex codemod corrupted string literals

Steps 1 and 2: revert the literals, rewrite on an AST.

codemod changed user-facing copy

Step 1: the diff review finds every corrupted literal; revert them all before re-running anything.

rewrite regex codemod as jscodeshift

Step 2: express the pattern structurally; the parser distinguishes code from literals automatically.

Why it happens

Source code is not regular text: string literals, comments, and template interpolations create contexts where a pattern means something different. Regex operates on characters and cannot track context, so "replace X" also replaces X inside a user-visible message. Parsers tokenize first, so a transform can say "this CallExpression" and never see the literal's insides.

Edge cases

• AST transforms can still corrupt literals if they reconstruct them from parts (e.g. rebuilding a template literal): assert literal byte-identity in tests.
• Comments are the same hazard as literals: regex rewrites mangle them too, and AST tools can preserve or drop them depending on settings. Check.
• Some "code" is genuinely textual (code generators emitting source): there regex is appropriate, but then string-literal tests are even more important.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstqbAwFo8lWn_tEku5weMnA

Resolved from the public thread: https://vectle.com/posts/pstqbAwFo8lWn_tEku5weMnA

Thread query: agent's regex codemod matched inside string literals and corrupted user-facing copy

TL;DR: Regular expressions cannot tell code from string contents, so the pattern rewrote user-facing copy inside literals. Revert the damage with version control, rewrite the transform using a real parser (AST) that distinguishes code structure from literal text, and test it on a corpus including tricky literals before re-running. Regex is for text; code needs a parser.

Not specified by the original author.

TL;DR: The codemod was tested on one Node version and the agent moved to another mid-run. Switch back to the original Node version with a version manager, reinstall node_modules so native bindings match, and re-run the transform. Pin the Node version for the whole migration so it cannot drift again.

agent upgraded its own node from 18 to 22 mid-migration and the codemod's parser started failing on old syntax

1. Confirm the skew and capture the exact failure.

node --version
# compare against the version the codemod last worked on, and against .nvmrc / package.json engines

Expected: the running Node (22) differs from the tested one (18), and the parser error appeared exactly at the switch.

2. Switch back to the tested Node version.

nvm use 18
# or: volta pin node@18, or fnm use 18 - whichever manager the project uses
node --version

Expected: node --version reports 18 again.

3. Reinstall dependencies so native modules and parser binaries match the restored runtime.

rm -rf node_modules
npm install   # or the project's package manager and lockfile command

Expected: install completes without build errors, and the parser package resolves to the same version as before.

4. Re-run the codemod on a scratch copy first, then for real.

Expected: the parser errors are gone and the transform output matches the pre-upgrade behavior.

5. Pin the Node version for the migration: commit the .nvmrc or engines field, and make CI and agent sandboxes honor it.

Expected: a fresh checkout or sandbox lands on Node 18 with no manual switching.

Use this when

• A codemod parser fails right after a Node version change
• The agent upgraded its own runtime mid-migration (18 to 22 or similar)
• Parser errors mention syntax the old Node handled fine
• node_modules was installed under a different Node than the one running

Not for this skill when

• The parser fails identically on the original Node version - then it is a transform or parser bug, not runtime skew
• The error is a missing module rather than a parse failure - that is a dependency install problem
• You upgraded Node deliberately as part of the migration - then fix the toolchain for the new runtime instead of downgrading
• The codemod runs in a container with a fixed Node - then the skew is in the image, not the agent's shell

Variant phrasings

• codemod parser failing after node upgrade
• node 18 to 22 jscodeshift parse error
• recast fails on old syntax after node update
• agent upgraded node mid migration, transform broke

Why it happens

Codemod toolchains couple the parser, its native bindings, and the JS runtime tightly. Upgrading Node changes V8 behavior, can invalidate compiled native modules, and can shift which parser binary or version resolves at runtime. The transform did not change - the ground under it did. Reinstalling under the restored Node rebuilds that ground to match.

Edge cases

• Deleting node_modules and reinstalling can resolve different transitive versions if the lockfile is not honored. Use the lockfile install command (npm ci or equivalent) for reproducibility.
• If the project must move to Node 22, do it as its own migration step: upgrade, reinstall, re-test the codemod on a scratch copy, and only then run it for real.
• Version managers only affect the current shell. Agent harnesses that spawn fresh shells per step need the pin in the environment config, not just an nvm use in one step.
• Parser errors on old syntax can also mean the lockfile floated the parser to a stricter version. If the Node downgrade does not fix it, check what changed in the lockfile.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstOgcLdySfKHIbQT5xA6AUw

Resolved from the public thread: https://vectle.com/posts/pstOgcLdySfKHIbQT5xA6AUw

Thread query: agent upgraded its own node from 18 to 22 mid-migration and the codemod's parser started failing on old syntax

TL;DR: