Current Behavior

The v23.0.0 migrate-create-nodes-v2-to-create-nodes migration (shipped in 22 plugins) rewrites only import/export named bindings of createNodesV2 to createNodes — it never touches value references in the file body.

So a lone import { createNodesV2 } (or one deduped against an existing createNodes) is renamed to import { createNodes }, but any value usage of createNodesV2 is left dangling:

import { createNodesV2 } from '@nx/js/typescript'; // → renamed to createNodes
addPlugin(graph, '@nx/js/typescript', createNodesV2, {}); // ← left as-is → TS2304: Cannot find name 'createNodesV2'

The existing specs only ever asserted on import lines, never on a file that uses createNodesV2 as a value, so the gap went unnoticed. (Found while running the migration against a real workspace.)

Expected Behavior

When the migration renames a local createNodesV2 import binding, it now also renames in-file value references to createNodes, so the file still compiles. The rename is AST-scoped and conservative — it skips:

• property accesses (x.createNodesV2) and qualified type names
• object-literal keys
• declaration names that shadow the import
• strings and comments (never Identifier nodes)

and expands a shorthand property ({ createNodesV2 } → { createNodesV2: createNodes }) to preserve the key. Aliased imports ({ createNodesV2 as cn }) and re-exports keep their local name, so they never trigger a usage rewrite.

Applied to all 22 plugin copies of the migration; regression tests added for the value-usage cases (21 specs; @nx/gradle's multi-specifier spec keeps its existing structure and the shared logic is covered by the others).

Related Issue(s)

N/A — follow-up hardening of the v23 migration.

View session information ↗