What is the purpose of props:true in no-param-reassign?

I’m just wondering how this is better than not having it. The only thing I can see it doing is causing code to go from…

login: (options) => {
    options.url = // stuff

to

login: (argsOptions) => {
    let options = argsOptions;
    options.url = // stuff

Which becomes something we can’t check for… Not to mention, attaching methods on an object is frequently done, as in the case of reduce’s accumulator (https://github.com/airbnb/javascript/issues/719). This is just part of Javascript. If you don’t want your object being muddled with by the function you’re sending it too, then you should look at

• Object.freeze()
• Object.seal()

I believe this is just being enabled by people who want things to be more strict… I don’t understand why you’d want this ever as a style rule. Can we look into answering why this should be used?, or why this shouldn’t be used? in the docs if we’re going to keep this around.

[EvanCarroll]

Sure, it’s the job to notify you of errors seems to be an excuse here… Though it’s not really an error, it’s just JavaScript: namely that the language itself is not call-by-value, but instead call-by-sharing. We’re assuming I don’t know that, and that’s why it’s “notifying” me (by triggering an error). But, we don’t assume that the user knows = is assign by reference and not by value. So the end result is that the user, in trying to work around the linter, makes the code more obtuse and solves no problems. So long as we agree that the behavior likely to arise out of

error    Assignment to function parameter 'options'       no-param-reassign

in

login: (options) => {
    options.url = // stuff

is a modification like this

login: (argsOptions) => {
    let options = argsOptions;
    options.url = // stuff

Because again, you have to know that a = b is not a = _.deepCopy(b)…

[EvanCarroll]

I fully agree mutation should be avoided, ideally. But, there is no “copy object” operator in JavaScript. It’s simply call by sharing. You’re going to be fighting this every step of the way. If you want to make the object frozen, your only option is to Object.freeze() from the caller. If you want to fundamentally change the way JavaScript works, you’d have to wrap every variable assignment through a deep copy. Shy of that, you have to use a library with _.cloneDeep() or roll you own version (which sounds horrendous).

As to your second example, I don’t see any reason why the linter can’t check for that too, but again the purpose is not to prevent programmers from doing bad things, it’s to prevent them from unknowingly doing bad things.

I’m not going to defend call by sharing. But, if the language is call by sharing, or call by reference you just have to learn it and accept the drawbacks. You can’t enforce call by value, and it seems pointless to warn people that they’re using JavaScript.

I’d be all for,

Warning, you’re using a loosely-typed dynamic multi-paradigm language with global state.

But, there is no reasonable way to fix that.