prefer-object-spread invalid autofix with accessors
See original GitHub issueTell us about your environment
- ESLint Version: 6.1.0
- Node Version: 10.16.0
- npm Version: 6.9.0
What parser (default, Babel-ESLint, etc.) are you using?
default
Please show your full configuration:
Configuration
module.exports = {
parserOptions: {
ecmaVersion: 2018,
},
};
What did you do? Please include the actual source code causing the issue, as well as the command that you used to run ESLint.
Example #1
/*eslint prefer-object-spread: "error"*/
const foo = { a:1 };
const bar = Object.assign(
{
get a() { return this._a },
set a(v) { this._a = v + 1 }
},
foo
)
console.log(bar.a) // 2
Example #2
/*eslint prefer-object-spread: "error"*/
const foo = Object.assign(
{},
{
get a() { return this._a },
set a(v) { this._a = v + 1 }
}
);
foo.a = 1;
console.log(foo.a) // 1
eslint index.js
What did you expect to happen?
Not to change behavior.
What actually happened? Please include the actual, raw output from ESLint.
Example #1
/*eslint prefer-object-spread: "error"*/
const foo = { a:1 };
const bar = {
get a() { return this._a },
set a(v) { this._a = v + 1 },
...foo
}
console.log(bar.a) // 1
Example #2
/*eslint prefer-object-spread: "error"*/
const foo = {
get a() { return this._a },
set a(v) { this._a = v + 1 }
};
foo.a = 1;
console.log(foo.a) // 2
Are you willing to submit a pull request to fix this bug?
Yes, just to define what should be done (no warning, warning without the fix or something else).
Issue Analytics
- State:
- Created 4 years ago
- Comments:16 (14 by maintainers)
Top Results From Across the Web
prefer-object-spread - ESLint - Pluggable JavaScript Linter
A pluggable and configurable linter tool for identifying and reporting on patterns in JavaScript. Maintain your code quality with ease.
Read more >@babel/plugin-proposal-object-rest-spread - Package Manager
Fast, reliable, and secure dependency management.
Read more >tslint-eslint-rules - npm Package Health Analysis | Snyk
Looks like tslint-eslint-rules is missing a security policy. ... no-invalid-this, disallow this keywords outside of classes or class-like objects.
Read more >ESLint/CHANGELOG and ESLint Releases | LibHunt
... e85d27a Fix: no-regex-spaces false positives and invalid autofix (fixes ... 644ce33 Fix: no-self-assign false positive with rest and spread in array ...
Read more >ValidateJavaScript - Online Tool to Find & Fix JavaScript Errors
accessor -pairs array-bracket-newline array-bracket-spacing ... no-invalid-regexp no-invalid-this ... prefer-rest-params prefer-spread prefer-template
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
After thinking about this again, I believe that
prefer-object-spread
shouldn’t even report in any of these cases.Even without the autofix, the rule would suggest using object literal/object spread instead, which is wrong as it isn’t equivalent. Maybe there could be another rule to warn about using getters/setters with
Object.assign
(to disallow that style if it’s intentional or find errors if it isn’t).Yes, fixing
x = Object.assign({}, { get a(){} })
tox = { get a(){} }
is certainly wrong.I’ll make a PR to ignore
Object.assign
if there are any getters/setters inside (as described in this comment), that seems like the most appropriate solution for this edge case.Semi-related,
__proto__
orsuper
in source objects would cause a similar bug, but it’s better to open a separate issue for these.