opened
EvanCarroll
username_0
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..

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

to

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

Which becomes something we can't check for... Not to mention, attaching methods on a 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()
What is the purpose of props:true in no-param-reassign?
issue
created
ilyavolodin
username_1
I believe this is the reason for `props` argument: https://github.com/eslint/eslint/issues/1600#issuecomment-113007156
comment
created
ljharb
username_2
It is a common (albeit not the only) coding style that mutation should be avoided in all its forms. JavaScript makes this very difficult. This particular rule causes a programmer who is mutating a passed-in object to have it brought to their attention - clearly there's a number of patterns that they can use to work around it, but that's not the point. The concern for me is that this linter warning will likely suggest them to copy the object (avoiding mutation), or, ask why it's bad (creating the discussion).

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.
comment
created
EvanCarroll
username_0
But, there is no reasonable way to fix that.
comment
created
ljharb
username_2
The warning here isn't to fix it - it's to prevent you from not knowing that what you're doing is dangerous. If you know what you're doing, that's what override comments are for, but the default should be for the linter to assume you don't realize you're doing it.
comment
created
ilyavolodin
username_1
@username_0 ESLint's job is not to prevent errors, it's to notify you when there's a potential for an error. We have other rules that go against JavaScript syntax. Like `no-use-before-define`. In JavaScript due to hoisting, this is not a problem, but a lot of developers come to JavaScript from other languages, and might not be aware of the potential problems that could occur due to JS syntax, so we warn them about it. You always have an option of turning off rule completely if you don't agree with those warning, or don't find them helpful (or even harmful/limiting in some cases).
comment
created
EvanCarroll
username_0
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. 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 from

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

in

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

is a modification like this

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

Because again, you have to know that `a = b` is not `a = _.deepCopy(b)`..
comment
created
ljharb
username_2
I would never expect (nor have I ever seen) someone bypass this linter rule with your second example, unless they are explicitly trying to sneak past the spirit of the linter rule.

At any rate, this is a rule that some of us find helpful. Thus, objectively, it is a useful rule to have. If you do not find it helpful, there's tons of easy ways to disable it! However, even if you are not convinced of its usefulness, the simple fact that others merely *say* it is useful to them makes it objectively so ¯\_(ツ)_/¯ 

It seems like the purpose of this rule has been explained, and I don't see `eslint` removing a rule many find useful simply because it can't convince somebody of its usefulness.
comment
created
ilyavolodin
username_1
Agree with @username_2 this is a useful rule for some people. If you do not find it useful, just turn it off in the config completely, and you will never have to worry about it's errors. Not every rule in ESLint apply to everyone, nor should they. We have a lot of users, and they do not have the same needs.
comment
closed
alberto
username_3
issue