feat: add the checkForEach option to useIterableCallbackReturn

[skearya]

Summary

Adds the "checkForEach" option to the "useIterableCallbackReturn" rule.

When enabled (default behavior) .forEach() callbacks will be checked to not return anything. When disabled the callbacks will not be checked for behavior. This option exists in the eslint rule.

Rule Option:

{
    "options": {
        "checkForEach": true
    }
}

Closes #8024

Relevant:
#8005

Test Plan

Docs

[changeset-bot]

🦋 Changeset detected

Latest commit: 572e679

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 14 packages

Name	Type
@biomejs/biome	Minor
@biomejs/cli-win32-x64	Minor
@biomejs/cli-win32-arm64	Minor
@biomejs/cli-darwin-x64	Minor
@biomejs/cli-darwin-arm64	Minor
@biomejs/cli-linux-x64	Minor
@biomejs/cli-linux-arm64	Minor
@biomejs/cli-linux-x64-musl	Minor
@biomejs/cli-linux-arm64-musl	Minor
@biomejs/wasm-web	Minor
@biomejs/wasm-bundler	Minor
@biomejs/wasm-nodejs	Minor
@biomejs/backend-jsonrpc	Patch
@biomejs/js-api	Major

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[coderabbitai]

Walkthrough

This pull request adds a new checkForEach configuration option to the useIterableCallbackReturn lint rule. The implementation introduces an optional boolean field to control whether forEach() callbacks should be checked for returning values. When disabled, forEach callbacks are skipped during analysis. Changes span the lint rule definition, options structure, and a new changeset entry documenting the minor release feature.

Suggested labels

A-Linter, L-JavaScript, A-Diagnostic

Suggested reviewers

• arendjr
• siketyan

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The pull request has no author-provided description, making it impossible to evaluate whether the description relates to the changeset.	Add a pull request description explaining the changes, such as: 'Adds a checkForEach option to the useIterableCallbackReturn rule to allow skipping forEach() callbacks from being checked.'

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change: adding a checkForEach option to the useIterableCallbackReturn rule.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[dyc3]

The default for the source rule is false. Matching the source rule is important because it makes migrating from eslint easier for users.

If we keep the default as true, IMO we can ship this in a patch release and then switch it to default to match the source rule later in a minor release. Or we could switch the default to false and ship this in a minor.

Personally, I'm in favor of the latter. Less work for everybody.

[dyc3]

if this is going to be a minor, the PR must point to next

[codspeed-hq]

CodSpeed Performance Report

Merging #8035 will not alter performance

_{Comparing skearya:feat/check-for-each (572e679) with main (2cef76a)¹}

Summary

✅ 53 untouched
⏩ 85 skipped²

Footnotes

1. No successful run was found on main (c09e45c) during the generation of this report, so 2cef76a was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

2. 85 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[ematipico]

Please check the contribution guide for how the format of options should be.

Since the default is true, there's little to no value showing an example with true. Instead, we should have an option block with false, and an example (with or without diagnostics) that shows how false works in that snippet/example.

Even if we change the default value of the option, the suggestion is still valid. We don't want to test the defaults, but the other values

[dyc3]

Still interested in this pr @skearya ?

[theshadow27]

I'm happy to pick it up if not, @dyc3 just didn't want to step on toes. These are super easy fixes

[ematipico]

Go ahead @theshadow27

Please make sure to cherry pick @skearya commits, so both of you get attributions

[theshadow27]

Go ahead @theshadow27

Please make sure to cherry pick @skearya commits, so both of you get attributions

Cool, no problem. See #8289