Rename "no-native-reassign" to "no-global-assign"

[jacksonrayhamilton]

As mentioned in #6395, the name of the rule "no-native-reassign" is confusing, because the rule covers more than native reassignments. The name was so misleading that no one realized the rule worked the way it did for several months. Therefore, I think the rule should be renamed to "no-global-assign".

One issue brought up in that thread was that a name change would be breaking. It doesn't have to be; we could have the old name (and docs url) alias the new one, promote the new name wherever possible, and mention the alias in the rule's documentation. Aliasing could be automated with metadata.

[platinumazure]

With our current infrastructure, this is a breaking change. If the necessary infrastructure changes are done to support aliasing (requires separate issue, discussion for acceptance, and pull request), then I'll remove the "breaking" label.

I'm personally 👍 for this change, even if we do it as a breaking change. The name of the rule right now is just plain wrong (IMO).

[nzakas]

We don't currently have a way of aliasing rules, so this is really a core enhancement request.

[nzakas]

Per TSC meeting, we agree that we should rename no-native-reassign to no-global-reassign for clarity. The no-native-reassign rule will be deprecated and fall under our regular deprecation policy (so as to avoid a breaking change).

This involves:

1. Copying all no-native-reassign files to corresponding no-global-reassign files
2. Making no-native-reassign.js just contain module.exports = require("./no-global-reassign") (similar for the tests)
3. Add no-native-reassign to deprecated section on website (design needed)

[jacksonrayhamilton]

Just to clarify, will the rule be called no-global-assign or no-global-reassign? (In the meeting notes the former is used, but in your comment above the latter is used.)

[ghost]

Can Proxies solve this issue? Not used them now but I can imagine Proxies are helpful in such a case.

[nzakas]

@jacksonrayhamilton ooh, nice catch, I completely missed that. I think no-global-assign makes more sense.

@fibric proxies do not help this use case.

[alberto]

@nzakas should we import the new one instead of just copying it? If it is deprecated, leaving the old copy intact seems reasonable to me. It shouldn't get future changes by means of the new rule.

[nzakas]

@alberto hmmm, good point. My concern was that having two rules that are the same would be confusing in the code base , but I suppose we can solve that by putting a deprecation comment at the top of the file.

[alberto]

There is a problem with this. no-native-reassign is part of eslint:recommended so I guess we can't disable it until next major? Should we create no-global-assign and replace it then?

[nzakas]

We weren't going to disable it, only deprecate it, so that shouldn't affect anyone.

This is also why I thought having one rule reference the other was a good idea, so the references act the same.

In any case, we can't change eslint: recommended until the next major version.