the agent's jscodeshift transform double-wrapped every component in Rea

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: Make the converted state detectable. Either write an explicit marker (a comment or a tracking file listing converted paths) or make the transform recognize its own output shape and skip it. The agent needs a cheap yes-or-no check per file before running the transform - without one, every resume or retry re-converts.

react codemod agent converted the same class components twice - it had no marker to tell converted files from unconverted ones

1. Define the marker: decide what "converted" looks like - a trailing attribution comment, an entry in a tracking file, or simply the absence of class components in the file. Expected: a rule you can state in one sentence.

2. Add the marker write to the transform: when the codemod converts a file, record it (append the path to the tracking file or leave the marker comment). Expected: converted files are identifiable without re-running the transform.

3. Add the marker check before converting: the agent lists candidate files, drops the ones already marked, and only transforms the rest. Expected: a second run over the repo converts zero files.

4. Handle the double-converted files already produced: revert them from version control, or re-run conversion from the original sources if the originals are tagged. Expected: no file contains the artifacts of two conversion passes.

5. Verify: run the agent loop twice over the full repo and diff the results. Expected: the second run is a complete no-op.

Use this when

• a React class-to-function codemod converts the same files twice
• an agent resumes a codemod run and cannot tell which files are done
• converted files are indistinguishable from unconverted ones

Not for this skill when

• the codemod produces wrong output on the first run - fix the transform logic
• files were hand-edited after conversion - that needs human review, not a marker
• you are converting a handful of files once - just do it and move on

Variant phrasings

• codemod converted class components twice, no idempotency marker
• agent re-ran react codemod on already-converted files
• how to track codemod progress across files

Why it happens

The agent's loop is "find class components, convert them" with no memory between passes. After the first pass converts a file, nothing records that fact - so a retry, a resume after a crash, or just a second loop iteration finds the file again. Whether the transform double-applies or merely wastes time depends on the transform, but the missing piece is the same: no durable record of what is done.

Edge cases

• A marker comment can be stripped by formatters - a tracking file outside the source tree survives formatting.
• If the transform is also idempotent (skips its own output shape), the marker is belt-and-suspenders - still worth having for the agent's planning step.
• Files added to the repo mid-migration (new branches merged in) will not be in the tracking file - re-scan for unconverted files at the end.
• Do not keep the tracking file as permanent documentation - archive or delete it when the migration is complete.

Provenance

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

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

Thread query: react codemod agent converted the same class components twice - it had no marker to tell converted files from unconverted ones

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.