fix: convert lint results per chunk to avoid OOM on large repos

[lolgab]

Summary

• lintFilesChunkByChunk accumulated every chunk's ESLint.LintResult[] (each carrying the full file source text) into one array for the whole repo, then converted everything at the end. Memory grew with repo size regardless of the 5MB per-chunk cap, causing JavaScript heap out of memory crashes on large repos even after the recent --max-old-space-size bump (Increase Node.js memory limits in entrypoint.sh #5017).
• Convert (and discard) each chunk's results immediately, keeping only lightweight ToolResult[] around for the rest of the run.

Test plan

• CI test suite
• npm run build (typecheck) passes locally

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 complexity · 0 duplication

Metric	Results
Complexity	0
Duplication	0

View in Codacy

AI Reviewer: first review requested successfully. AI can make mistakes. Always validate suggestions.

_{TIP This summary will be updated as you push new changes.}

[codacy-production]

Pull Request Overview

While the PR correctly identifies the memory bottleneck caused by accumulating heavy ESLint.LintResult objects, the implementation contains a logic gap where glob patterns bypass the chunking logic entirely, likely leaving the OOM risk unresolved for many users. Additionally, the final processing steps create a secondary memory peak by mapping the full results array at once. The Codacy analysis is currently 'up to standards', but the 'MissingRequirements' coverage status and lack of new tests suggest a high risk of regression. Addressing the glob expansion and optimizing the final collection phase is recommended before merging.

About this PR

• No unit tests or integration tests were provided to verify that the chunking logic correctly converts results or that memory is actually freed. The 'Test plan' in the PR description was also left empty.

Test suggestions

• Verify that results from each chunk are converted to ToolResult before the next chunk starts.
• Verify that the final output from engineImpl contains the expected relative paths for all ToolResults.
• Verify that globs in the input files still result in converted ToolResult objects.

Prompt proposal for missing tests

Consider implementing these tests if applicable:
1. Verify that results from each chunk are converted to ToolResult before the next chunk starts.
2. Verify that the final output from engineImpl contains the expected relative paths for all ToolResults.
3. Verify that globs in the input files still result in converted ToolResult objects.

_{TIP Improve review quality by adding custom instructions
TIP How was this review? Give us feedback}

[codacy-production]

_{🔴 HIGH RISK}

The OOM prevention logic is bypassed when glob patterns are detected (e.g., **/*.js). Since default configurations frequently use globs, eslint.lintFiles(files) will still load all results into memory at once, defeating the purpose of this fix. Consider expanding globs into a flat list of explicit file paths before the chunking logic to ensure consistent memory usage. You can use a library like fast-glob to resolve these patterns.

[codacy-production]

_{🟡 MEDIUM RISK}

Suggestion: Using the spread operator (...) with results.push can trigger a RangeError: Maximum call stack size exceeded in Node.js if a chunk contains a very large number of linting issues (typically > 65k). A loop is safer for merging large result sets:

Suggested change

	results.push(...convertResults(chunkResults))
	convertResults(chunkResults).forEach((r) => results.push(r))

[codacy-production]

_{🟡 MEDIUM RISK}

Suggestion: Calling .map() on the full results array at the end doubles the memory required for the results list right before the function returns. To minimize memory pressure, consider mapping to relative paths earlier within the chunking loop so the final array only contains the finished objects.