the jscodeshift transform wasnt idempotent

Not specified by the original author.

TL;DR: Guard the transform so it skips nodes it has already converted. Before rewriting a node, check whether the output shape is already present - if the code already looks converted, return the node unchanged. An idempotent transform is a no-op on its own output, which makes re-runs, retries, and agent resume-after-crash all safe.

codemod agent rewrote the same file 3 times - the jscodeshift transform wasnt idempotent and kept re-matching its own output

1. Reproduce the double-apply on one file: run the transform on an already-converted file and diff before against after. Expected: the diff is non-empty - it shows exactly what the transform changes on its own output.

2. Add a skip guard at the top of the visitor: if the node already has the converted shape (the new import already exists, the wrapper is already applied), return the node unchanged. Expected: re-running on the converted file now produces an empty diff.

3. Tighten the matcher so it cannot match its own output: match only the old API name, never the new one the transform creates. Expected: a codebase-wide second run reports zero changed files.

4. Verify idempotency on the full repo: run the transform twice over everything and diff the second run's output against the first. Expected: the second run changes nothing.

5. For the agent loop: after each transform pass, record a checksum of changed files and skip files whose checksum matches the post-transform state on resume. Expected: a crashed-and-resumed run never re-processes finished files.

Use this when

• a jscodeshift transform changes files every time it runs, including on its own output
• an agent re-runs a codemod after a crash and gets double-wrapped or double-renamed code
• the same file appears in the changed list on every pass with no real progress

Not for this skill when

• the transform crashes or throws - that is a bug in the visitor, not idempotency
• the transform is intentionally run once and deleted - though idempotency is still good practice
• the problem is the parser choking on syntax, not repeated rewrites

Variant phrasings

• jscodeshift transform not idempotent, re-matches own output
• codemod double-applies changes on second run
• transform keeps rewriting already-converted files

Why it happens

A jscodeshift visitor matches patterns in the AST and rewrites them. If the rewrite produces code that still matches the visitor's pattern - a wrapper around a node the matcher also accepts, a renamed import the rename rule still matches - then every run converts the output of the previous run. The agent re-running the codemod (retry, resume, or just caution) amplifies a transform bug into triple-wrapped code.

Edge cases

• Skip guards based on exact string matching can miss semantically identical variants - match on AST shape, not source text.
• A guard that is too broad skips files that genuinely need conversion (for example, skipping every file containing the new import, even ones that also use the old API). Guard per node, not per file, where possible.
• If the transform already ran 3 times on the repo, fix the triple-applied files first (revert from version control or write an unwrap transform) before making it idempotent.
• Test the transform on a fixture that is already fully converted - most codemod test suites only test the unconverted input.

Provenance

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

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

Thread query: codemod agent rewrote the same file 3 times - the jscodeshift transform wasnt idempotent and kept re-matching its own output

TL;DR:

Not specified by the original author.

TL;DR: Guard the visitor so it skips components that are already wrapped. Before wrapping, check whether the export's declaration is already a call to React.memo (or a bare memo import) and return the node unchanged if so. Then prove idempotency: run the transform twice on a fixture and require the second run to produce an empty diff.

The problem as reported:

the agent's jscodeshift transform double-wrapped every component in React.memo on the second run - the transform wasnt idempotent and the agent couldnt run it twice

1. Open the transform and find the visitor that wraps components (usually on ExportDefaultDeclaration or FunctionDeclaration).
2. Add a guard function and call it before wrapping:

function alreadyWrapped(decl) {
  if (decl.type !== 'CallExpression') return false;
  var c = decl.callee;
  if (c.type === 'MemberExpression' &&
      c.object.name === 'React' && c.property.name === 'memo') return true;
  if (c.type === 'Identifier' && c.name === 'memo') return true;
  return false;
}

root.find(j.ExportDefaultDeclaration).forEach(function(p) {
  var decl = p.node.declaration;
  if (alreadyWrapped(decl)) return;
  p.node.declaration = j.callExpression(
    j.memberExpression(j.identifier('React'), j.identifier('memo')),
    [decl]
  );
});

Expected: the transform reads cleanly and the guard covers both React.memo and bare memo call styles.

3. Run it twice on a sample file, then check the diff after the second run. Expected: the first run shows the wrapping; the second run changes nothing.
4. Add the double-run check to CI for every transform in the repo. Expected: any future non-idempotent transform fails the build instead of corrupting the codebase.

Use this when

• A codemod produces different output when run twice.
• Components end up wrapped in memo(memo(...)) or similar doubled constructs.
• You need a transform to be safely re-runnable mid-migration.

Not for this skill when

• The transform is a one-shot script you'll delete after the migration.
• The doubling comes from two different transforms running in sequence - that's a composition problem, fix the pipeline order instead.

Variant phrasings

• jscodeshift transform not idempotent
• codemod runs twice different result
• React.memo applied twice by codemod
• transform matches its own output

Why it happens

The matcher's predicate describes the pre-transform shape ("a default-exported function"), but the transform's output (a default-exported call expression wrapping that function) still satisfies a loose predicate, so every run wraps again.

Edge cases

• memo imported under an alias: match on the import binding, not the call name.
• Components already wrapped in other HOCs like forwardRef: decide whether memo goes inside or outside and guard for both orders.
• Class components need a different guard shape than function components - don't share one predicate for both.

Provenance

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

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

Thread query: the agent's jscodeshift transform double-wrapped every component in React.memo on the second run - the transform wasnt idempotent and the agent couldnt run it twice

TL;DR:

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: