feat: add codemod for iterate-iterator

[babs20]

Codemod for iterate-iterator

[zloirock]

Iterators are not always iterable, so for proper work in for-of and Array.from they should be wrapped to { [Symbol.iterator](){ return iterator } }.

[babs20]

@zloirock I think that case it not intended to be handled by the package this codemod replaces. That seems like a case we would cover when we create the codemod for the iterate-value package

[zloirock]

Try something like this:

[babs20]

@zloirock Thank you for pointing that out! Added logic to use [Symbol.iterator] and an additional test case based on your comment.

[babs20]

Anything I can update to help complete this PR?

[Copilot]

Pull request overview

This PR adds a codemod to migrate from the iterate-iterator npm package to native JavaScript alternatives. The codemod transforms calls to iterateIterator() into native for...of loops and Array.from() constructions.

Key changes:

• Adds transformation logic to convert single-argument calls to Array.from() with a custom iterator
• Transforms two-argument calls (with callbacks) to for...of loops
• Handles both ES6 imports and CommonJS requires

Reviewed changes

Copilot reviewed 12 out of 13 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
codemods/iterate-iterator/index.js	Main codemod implementation that transforms iterate-iterator calls to native JavaScript
types/codemods/iterate-iterator/index.d.ts	TypeScript type definitions for the codemod
test/fixtures/iterate-iterator/case-1/*	Test fixtures for ES6 import scenario with various transformation patterns
test/fixtures/iterate-iterator/case-2/*	Test fixtures for CommonJS require scenario with various transformation patterns
test/fixtures/iterate-iterator/case-3/*	Test fixtures for arrow functions with parenthesized parameters
package.json	Adds package export entry for the new codemod
index.js	Imports and registers the iterate-iterator codemod in the codemods registry

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The transformation uses a hardcoded variable name i for the loop variable when handling function expressions and arrow functions with block bodies. While this is semantically correct, it results in less readable code compared to extracting the parameter name from the callback function.

For example:

iterate(items, function(item) { console.log(item); })

Currently transforms to:

for (const i of {...}) {
  (function(item) { console.log(item); })(i);
}

It would be more readable to extract the parameter name item and generate:

for (const item of {...}) {
  (function(item) { console.log(item); })(item);
}

Or even better, extract the function body and simplify to:

for (const item of {...}) {
  console.log(item);
}

This would be consistent with how the arrowCalls section handles arrow functions with expression bodies (lines 63-78).

Suggested change

	const needsParens =
	callbackKind === 'function_expression' ||
	callbackKind === 'arrow_function';
	const callbackCall = needsParens
	? `(${callback})(i)`
	: `${callback}(i)`;
	const replacement = `for (const i of {\n [Symbol.iterator]: () => ${arg1Match.text()}\n}) {\n ${callbackCall};\n}`;
	let loopVar = 'i';
	if (
	callbackKind === 'function_expression' ||
	callbackKind === 'arrow_function'
	) {
	const paramMatch = callback.match(
	/^(?:\s*(?:async\s*)?function\b[^(]*\(\s*([^,\s()]+)\s*\)|\s*(?:async\s*)?\(?\s*([^,\s()]+)\s*\)?\s*=>)/s
	);
	const paramName =
	paramMatch && (paramMatch[1] || paramMatch[2]);
	if (paramName) {
	loopVar = paramName;
	}
	}
	const needsParens =
	callbackKind === 'function_expression' ||
	callbackKind === 'arrow_function';
	const callbackCall = needsParens
	? `(${callback})(${loopVar})`
	: `${callback}(${loopVar})`;
	const replacement = `for (const ${loopVar} of {\n [Symbol.iterator]: () => ${arg1Match.text()}\n}) {\n ${callbackCall};\n}`;

[Copilot]

The code handles two-argument calls with arrow functions by splitting the logic across two sections: arrowCalls (lines 51-79) handles arrow functions with expression bodies, while otherCalls (lines 81-116) handles arrow functions with block bodies and function expressions. While this approach works correctly, it makes the code harder to understand because:

1. The relationship between the two sections isn't immediately clear
2. A reader must mentally track that arrow functions are handled in two different places based on their body type
3. The otherCalls name doesn't accurately describe that it also handles a specific subset of arrow functions

Consider consolidating the two-argument callback handling into a single section with clearer conditional logic, or at minimum, add comments explaining why arrow functions are split across these two sections.