Update: Array.prototype.flatMap in array-callback-return (fixes #12235)

[mdjermanovic]

What is the purpose of this pull request? (put an "X" next to item)

[X] Changes an existing rule #12235

This PR adds Array.prototype.flatMap to the list of targeted methods in array-callback-return, but only when ecmaVersion is set to 2019 or higher, in order to minimize potential breaking change impact.

This can produce more errors by default (for an ecmaVersion >= 2019 configuration only).

What changes did you make? (Give an overview)

Added flatMap to the pattern if ecmaVersion >= 10.

Also fixed two links in the documentation.

Is there anything you'd like reviewers to focus on?

Would be probably more correct to check enabled environments instead of the ecmaVersion, but that isn't possible at the moment as far as I know.

The diff looks big, most of it is just copy & paste to a different location.

[ljharb]

as a side note, all of these links shouldn't be to the always-obsolete snapshots on ecma-international.org, but rather to the only correct version of the spec, https://tc39.es/ecma262/

[mdjermanovic]

I'd like to fix the links in another PR, as two of them are partially broken (wrong #).

I understand that https://tc39.es/ecma262/ link represents the actual version much more than a draft, but it's officially still a draft? Also, it has the Draft word in the title, so I'm not sure is it OK to use this link, or just fix the links to ES2015. Or maybe change all links to ES2019.

[ljharb]

It’s a living standard; whatever’s on github is always the latest version.

[mysticatea]

Thank you for contribution. But I'd like to defer to merge as a breaking change until 7.0.0. Because [1, 2, 3].flatMap(() => {}) is not runtime errors and it can break user's builds.

[ljharb]

Can it be added behind an option now, and then turned on by default in v7?

[mysticatea]

I'm not a big fan of adding an option for only flagMap. This is similar to waiting for the rest change of #11803 until 7.0.0.

[platinumazure]

As a side note, I would be interested in seeing if we could do a 7.0.0 release soon. It would be nice to get into the habit of doing smaller, more frequent major releases. But I know some users already struggle to do major version upgrades even if we do them infrequently...

[mdjermanovic]

Just a thought, perhaps the rule could have an option - array of additional method names. That would avoid similar problems in the future.

Albeit, that could turn this rule into a generic configurable "callback-return" rule, so I'm not sure if this is a good idea.

[ljharb]

More frequent majors is a heavy burden on shared configs and plugins.

[mdjermanovic]

For v7.0.0, is there a need to check ecmaVersion >= 10? This was intended to decrease the breaking impact in a semver-minor version, but adds some complexity to the code.

As a similar thing, there is no ecmaVersion >= 6 check for find and findIndex

[platinumazure]

I agree there is probably no need to check ecmaVersion if we just label this as breaking and add it in 7.0.0.

[mdjermanovic]

@kaicataldo I added 'do not merge' because this needs to be changed if there is no need to check ecmaVersion. Sorry, I should have left a note.

[kaicataldo]

Ah, sorry! I should have asked. I was removing "do not merge" labels from "breaking" changes because we're now able to merge semver-major PRs in preparing for our first v7 alpha release.

[mdjermanovic]

Closing this in favor of #12765.

It seemed much easier to just make a new PR in this case.