Change Request: no-param-reassign doc page mention strict mode

[stephen-hardy]

ESLint version

v8.41

What problem do you want to solve?

The documentation page for no-param-reassign currently references a consideration for mutating the arguments object. Which, is valid in "sloppy mode". But, if I'm reading this MDN page correctly, this is no longer a concern in strict mode. Given the proliferation of enforced strict mode features, like classes and modules, many scenarios no longer need this rule to avoid argument object mutation.

Now, there are other reasons to avoid parameter reassignment. To my knowledge, none are performance concerns. And, none are more blatant footguns - like argument object mutation. So, for me as someone who wants every line of JS to be in strict mode, I think I no longer have a reason to avoid parameter reassignment. Other devs will differ, but I think it would be helpful for the documentation page to let people know that they no longer need this rule to avoid the problems referenced in this page's Further Reading section.

What do you think is the correct solution?

I'd change...

"... as modifying function parameters will also mutate the arguments object."

to

"... as modifying function parameters will also mutate the arguments object when not in strict mode (see When Not To Use It below)"

And add the following to the When Not to Use It section:

Strict mode code doesn't sync indices of the arguments object with each parameter binding. Therefore, this rule is not necessary to protect against arguments object mutation in ESM modules or other strict mode functions.

Participation

• I am willing to submit a pull request for this change.

Additional comments

I've been writing strict mode code for so long, I had forgot what all the effects were. Most articles and comments online were talking about how this rule prevents object mutation, and nobody was talking about how that might not be much of a thing anymore. I just happened to look up the MDN article on arguments out of curiosity, and then found this.

I tend to use the ESLint documentation pages as my starting place for determining whether I want a rule enabled. So, while people may still want this rule enabled, this should have the information up front about what it may or may not really be doing for them in the modern environment. The article included in Further Reading is from 2011, so there is a lot of outdated commentary on this subject.

Also, if anybody knows of remaining arguments for not reassigning parameters, I'd be curious to hear them. Frankly, I don't care if someone thinks it is a code smell - to each their own on that - but if it is a performance cost or a serious risk to unexpected behavior (like arguments mutation), I'd really like to know if I'm missing anything.

[mdjermanovic]

Hi @stephen-hardy, thanks for the issue!

Updating the docs for this rule with the strict mode behavior sounds good to me. PR is welcome.

but if it is a performance cost or a serious risk to unexpected behavior (like arguments mutation), I'd really like to know if I'm missing anything.

I'm not aware of any other cases of unexpected behavior like arguments mutation. As for the performance, the only thing I was able to find is "optimization issues" mentioned in the airbnb guide here and in airbnb/javascript#641 (comment). That may or may not be true with the actual engines, but either way since the docs for this rule don't mention performance let's keep it that way.

[stephen-hardy]

PR created.