New: Adds prefer-object-spread rule (refs: #7230) #9955

sharmilajesupaul · 2018-02-06T21:59:44Z

What is the purpose of this pull request? (put an "X" next to item)

New rule (template)

What changes did you make? (Give an overview)
This is a follow up to #7230, we implemented prefer-object-spread internally at @airbnb.
The rule requires that you use an object spread over an Object.assign call with multiple arguments and an object literal as the first argument.

We also warn on cases where an Object.assign call is made using a single argument that is an object literal, in this case, the Object.assign is not needed (7f7f97d).

The following patterns are considered errors:

Object.assign({}, foo)

Object.assign({}, {foo: 'bar'})

Object.assign({ foo: 'bar'}, baz)

Object.assign({ foo: 'bar' }, Object.assign({ bar: 'foo' }))

Object.assign({}, { foo, bar, baz })

Object.assign({}, { ...baz })

// Object.assign with a single argument that is an object literal
Object.assign({});

Object.assign({ foo: bar });

The following patterns are not errors:

Object.assign(...foo);

// Any Object.assign call without an object literal as the first argument
Object.assign(foo, { bar: baz });

Object.assign(foo, Object.assign({ bar: 'foo' }));

Object.assign(foo, { bar, baz })

Object.assign(foo, { ...baz });

Is there anything you'd like reviewers to focus on?

I made 2 commits in this PR

6e3e035 handles the general use case where Object.assign is called using an object literal and an additional argument, which can be changed to use object spread.
7f7f97d warns on cases where Object.assign has a single argument that is an object literal. In this case, you can use the object literal directly. (i.e. Object.assign({}) -> {})

I left the second part in its own commit because I wasn't sure if it would fit into the scope of this rule.

cc. @ljharb

mysticatea

Thank you for the contribution!!
Looks nice to me, but I left some requests.

About 7f7f97d, I'm not sure if it should be a part of this rule, but I don't oppose it.

mysticatea · 2018-02-07T03:20:09Z

lib/rules/prefer-object-spread.js

+                ) {
+                    context.report({
+                        node,
+                        message:


Would you use messageId instead message?

mysticatea · 2018-02-07T03:21:35Z

tests/lib/rules/prefer-object-spread.js

+        {
+            code: "Object.assign(foo, { bar: baz })",
+            parserOptions
+        }


Would you add tests for ecmaVersion: 2018?

mysticatea · 2018-02-07T03:26:35Z

lib/rules/prefer-object-spread.js

+
+    create: function rule(context) {
+        return {
+            CallExpression: node => {


Would you use a consistent way for create and CallExpression (e.g., method shorthand)?

I wonder if we have enabled object-shorthand rule in our codebase. 🤔

mysticatea · 2018-02-07T03:31:30Z

lib/rules/prefer-object-spread.js

+        docs: {
+            description:
+                "disallow using Object.assign with an object literal as the first argument and prefer the use of object spread instead.",
+            category: "ECMAScript 6",


Would you change the category to Stylistic Issues?

ES6 doesn't look proper category. Though it has not done, #7991 has been accepted.

mysticatea · 2018-02-07T03:43:16Z

tests/lib/rules/prefer-object-spread.js

+                    type: "CallExpression"
+                }
+            ]
+        }


Would you add tests for comments and parentheses? I expect comments to be kept.

For example:

Object.assign( {}, // a comment foo, // another comment { a: true } )

Object.assign( {}, ({ a }), b ? c : { d }, (e, f) )

mysticatea · 2018-02-07T03:49:10Z

lib/rules/prefer-object-spread.js

+ * @returns {Function} autofixer - replaces the Object.assign with a spread object.
+ */
+function autofixSpread(node, sourceCode) {
+    return fixer => {


I guess this might be able to simplify with generator function. (It's just a impression)

could you give me an example of this? I'm not too familiar with generator functions.

mysticatea · 2018-02-07T03:51:46Z

docs/rules/prefer-object-spread.md

+
+When Object.assign is called using an object literal the first argument, this rule requires using the object spread syntax instead. This rule also warns on cases where an `Object.assign` call is made using a single argument that is an object literal, in this case, the `Object.assign` call is not needed.
+
+**Please note:** This rule can only be used when using an `ecmaVersion` of 2018 or higher, 9 or higher, or when using an `ecmaVersion` of 2015-2017 or 5-8 with the `experimentalObjectRestSpread` parser option enabled.


I think that the note about experimentalObjectRestSpread doesn't need since the option would be removed in nearly future.

sharmilajesupaul · 2018-02-08T19:19:20Z

Thanks for the comments @mysticatea! I'll get to these tomorrow or Saturday at the latest, just fyi.

platinumazure · 2018-03-22T14:29:09Z

Hi @sharmilajesupaul, just wanted to follow up and ask if this is ready for another round of review or if there is more to be done here. Thanks!

sharmilajesupaul · 2018-03-22T20:34:50Z

@platinumazure yes yes wow I completely forgot, sorry! I spent a bunch of time addressing multiline objects that warn on this rule and never updated my PR, I will update it today

sharmilajesupaul · 2018-03-23T06:23:30Z

Made a big change to the fixer to work with multiline objects. Now it spreads object literal arguments instead of spreading them. Also addressed a majority of last code review requests. I haven't worked with generators much, so I'm not sure how that will work for the fixer? cc. @ljharb @platinumazure @mysticatea

platinumazure

Requesting some small documentation changes. Haven't had time to review the code/tests yet, but I hope to do so in the next few days. Thanks!

platinumazure · 2018-03-23T13:23:14Z

docs/rules/prefer-object-spread.md

@@ -0,0 +1,47 @@
+# Prefer use of an object spread over `Object.assign` (prefer-object-spread)
+
+When Object.assign is called using an object literal the first argument, this rule requires using the object spread syntax instead. This rule also warns on cases where an `Object.assign` call is made using a single argument that is an object literal, in this case, the `Object.assign` call is not needed.


Small typo: "using an object literal the first argument" --> "using an object literal as the first argument".

Also, we generally prefer that the first section should only have background about object spread and Object.assign-- the Rule Details section is where the rule's purpose/method should be outlined.

platinumazure · 2018-03-23T13:24:36Z

docs/rules/prefer-object-spread.md

+
+## Rule Details
+
+The following patterns are considered errors:


Could this be replaced with:

Examples of **incorrect** code for this rule:

Thanks!

platinumazure · 2018-03-23T13:24:51Z

docs/rules/prefer-object-spread.md

+Object.assign({ foo: bar });
+```
+
+The following patterns are not errors:


Could this be replaced with:

Examples of **correct** code for this rule:

Thanks!

This was an exception to this rule that we use internally, in the case that an `Object.assign` call is made with an object literal as the only argument. The `Object.assign` call is not needed and we can just use the object literal directly.

- handles nested object literals - handles various comment types - places comma after arguments in a smarter way

sharmilajesupaul · 2018-04-13T02:16:38Z

Just pushed updates to this PR:

now using emcaVersion: 2018 in tests (https://github.com/eslint/eslint/pull/9955/files#diff-6088f3cff25518533d89b2e8a4d395faR14)
added tests for multiple comment types and multiline objects (https://github.com/eslint/eslint/pull/9955/files#diff-6088f3cff25518533d89b2e8a4d395faR202)
added tests for cases where we do not need parens around an object literal (https://github.com/eslint/eslint/pull/9955/files#diff-6088f3cff25518533d89b2e8a4d395faR370)

Sorry it took so long!

cc @platinumazure, @mysticatea, @ljharb

ljharb

LGTM - all the spacing seems reasonable and adjustable via other rules, and using parens wherever it's not known to be safe (because the object literal might be a block) seems the right call.

platinumazure

Finally had time to review this in full (thanks for stopping by the Gitter chat). This is looking great on the whole, love the test cases (including coverage on comments, even HTML comments).

I left a few minor questions and nitpicks. I'm fairly confident at least one or two of them are non-contentious so I've labeled this review as Request Changes.

Thanks for all your hard work (and patience!) on this.

platinumazure · 2018-04-24T14:08:53Z

docs/rules/prefer-object-spread.md

+// Any Object.assign call without an object literal as the first argument
+Object.assign(foo, { bar: baz });
+
+Object.assign(foo, Object.assign({ bar: 'foo' }));


Question: Should the inner (second) Object.assign be flagged here? If so, would it be better to add a non-literal first argument so the whole line is a correct example?

yeah it should good catch

platinumazure · 2018-04-24T14:12:25Z

lib/rules/prefer-object-spread.js

+ */
+function addComma(arg) {
+    const nonWhitespaceCharacterRegex = /[^\s\\]/g;
+    const commentRegex = /(\/\*[\w'\s\r\n*]*\*\/)|(\/\/[\w\s']*)|(<![-\-\s\w>/]*>)/g;


Rather than taking a string and matching for comments, would it make more sense to use token/comment retrieval methods in SourceCode? I think this basically boils down to getting the last non-comment token in the argument node, and adding a comma afterward.

Thank you for mentioning this. Instead of the regex, we can just use the ranges in context.getCommentsInside(node). Definitely over complicated this a bit 😬

platinumazure · 2018-04-24T14:12:52Z

lib/rules/prefer-object-spread.js

+    const nonWhitespaceCharacters = Array.from(matchAll(arg, nonWhitespaceCharacterRegex));
+    const commentRanges = [];
+
+    // Create a ranges of starting and ending indicies for comments found


Nit: s/indicies/indices

platinumazure · 2018-04-24T14:15:33Z

lib/rules/prefer-object-spread.js

+    create: function rule(context) {
+        return {
+            CallExpression(node) {
+                const sourceCode = context.getSourceCode();


Nit: You could move this a few lines up so that we don't need to retrieve the SourceCode object on every CallExpression. (It's a persistent reference.)

platinumazure · 2018-04-24T14:17:06Z

tests/lib/rules/prefer-object-spread.js

+        "let a = Object.assign(a, b)",
+        "Object.assign(a, b)",
+        "let a = Object.assign(b, { c: 1 })",
+        "let a = Object.assign({}, ...b)",


Should this be valid? Wondering if the correct code should be let a = Object.assign(...b);, or am I missing something? (Compare with the test case 2 lines below this one)

Statement and expression positions differ in terms of how the autofixer outputs parens, but good call, this one should be a spread.

platinumazure · 2018-04-24T14:18:41Z

tests/lib/rules/prefer-object-spread.js

+            ]
+        },
+
+        // TODO: Handle nested Object.assign calls


Should this comment be removed? (Although, now I see some of the test cases below, seems there might be more to do here?)

platinumazure · 2018-04-24T14:19:23Z

tests/lib/rules/prefer-object-spread.js

+            errors: [
+                {
+                    messageId: "useSpreadMessage",
+                    type: "CallExpression"


Could this error (and the one below) have more information to help identify where the errors are reported? (e.g., line/column)

platinumazure · 2018-04-24T14:20:21Z

tests/lib/rules/prefer-object-spread.js

+        {
+            code:
+                "Object.assign({ foo: 'bar' }, Object.assign({ bar: 'foo' }, Object.assign({}, { superNested: 'butwhy' })))",
+            output: "({foo: 'bar', ...Object.assign({ bar: 'foo' }, Object.assign({}, { superNested: 'butwhy' }))})",


I think the innermost Object.assign should be identified and fixed-- is that a known limitation at this point? Or are we relying on multipass autofix to catch these cases? (Now the TODO above makes more sense...)

Multipass, i think.

I had a solution earlier that would recurse through nested object.assign calls, but the current implementation relies on multipass

platinumazure · 2018-04-24T14:21:18Z

tests/lib/rules/prefer-object-spread.js

+            errors: [
+                {
+                    messageId: "useSpreadMessage",
+                    type: "CallExpression"


Could this error (and the ones below) have more information, e.g. line/column numbers?

- adds line and column numbers to tests - warn on cases where argument is a spread element, - use getCommentsInside instead of regex - fix example in doc

sharmilajesupaul · 2018-05-07T20:53:54Z

@platinumazure ptal, made improvments in 7a7960a

platinumazure

Left one comment inline.

In addition, I'm not sure about the Object.assign({ objLiteral: "value" }) case. There's no check (that I can see) which checks that this is actually Object.assign. Could you please add a test foo({ bar: "baz" }) and show that this is not reported?

Also, I'm not sure how the case where Object is overwritten is handled: const Object = {}; Object.assign({ foo: "bar" }); (ideally should not report). I don't think this should block the release of this feature for now, though-- we can fix later.

platinumazure · 2018-05-10T19:59:51Z

lib/rules/prefer-object-spread.js

+        schema: [],
+        fixable: "code",
+        messages: {
+            useSpreadMessage: "Use an object spread instead of `Object.assign()` eg: `{ ...foo }`",


I don't think the example should be necessary. Users can view the documentation (or search the Internet) for what object spread means.

It's much more helpful to get the warning in-editor, though :-/ is there any reason the example can't be included?

Well, turning that around, why doesn't the object literal case have an example?

Also: Since we have autofix here, the user could just let that be run and see how the item should look. (And no, we don't need to note that --fix could be run in the lint message, because we note that in most formatters outside of the lint message)

I suppose that's a fair point - maybe it should have an example :-)

(also since autofix can't be easily run for a single rule, that's not really a practical option for demonstrating the results of a single rule)

…arn. Bug fix to ensure that an we're warning on an `Object.assign` for the literal case.

sharmilajesupaul · 2018-05-11T20:06:10Z

@platinumazure there should have been a line in the object literal case, to make sure that it was only warning on Object.assign, not sure how I missed that. But I added it back in along with the test case:
751774d#diff-c7ab2d044a2d5cc255c07ea6116488e1R267

I also updated the rule to pick up on whether the native Object is overwritten in a variable declaration or assignment in the current file. 751774d#diff-c7ab2d044a2d5cc255c07ea6116488e1R210

not-an-aardvark

Sorry about the late review, I just had one question about whether it's necessary to add a dependency.

not-an-aardvark · 2018-05-11T23:41:47Z

lib/rules/prefer-object-spread.js

+ */
+function addComma(formattedArg, comments) {
+    const nonWhitespaceCharacterRegex = /[^\s\\]/g;
+    const nonWhitespaceCharacters = Array.from(matchAll(formattedArg, nonWhitespaceCharacterRegex));


Is it necessary to use matchAll here? Since this regex doesn't have any capturing groups, it seems like this could just be done with:

const nonWhitespaceCharacters = formattedArg.match(nonWhitespaceCharacterRegex);

That would avoid the need to add a dependency on string.prototype.matchall.

With a global regex, .match does not return an array of match objects, so there's no way to get the index (position) of each match - this is the entire reason .matchAll is needed in the language.

So, no, I don't think there's any way to avoid the dependency (without inlining it, of course, which would be a terrible idea)

eslint-deprecated bot added the triage An ESLint team member will look at this issue soon label Feb 6, 2018

sharmilajesupaul changed the title ~~New: Adds prefer-object-spread rule (refs: #7230)~~ New: Adds prefer-object-spread rule (refs: #7230) Feb 6, 2018

mysticatea reviewed Feb 7, 2018

View reviewed changes

mysticatea added rule Relates to ESLint's core rules accepted There is consensus among the team that this change meets the criteria for inclusion feature This change adds a new feature to ESLint and removed triage An ESLint team member will look at this issue soon labels Feb 7, 2018

platinumazure requested changes Mar 23, 2018

View reviewed changes

This was referenced Apr 3, 2018

merge into core eslint bryanrsmith/eslint-plugin-prefer-object-spread#56

Open

Rule for rest spread missuse #8118

Closed

sharmilajesupaul added 5 commits April 12, 2018 19:11

New: Adds prefer-object-spread rule (refs: eslint#7230)

c0b3ec2

Refactors and adds multiline object fixes

1c032db

Many fixes and improvements:

4db39db

- handles nested object literals - handles various comment types - places comma after arguments in a smarter way

Fixes typo and improves wording in docs

3819ad4

sharmilajesupaul force-pushed the shar--prefer-object-spread branch from 97c0127 to 3819ad4 Compare April 13, 2018 02:12

ljharb approved these changes Apr 13, 2018

View reviewed changes

include string.prototype.matchall in package.json

e39fd2d

platinumazure requested changes Apr 24, 2018

View reviewed changes

Several improvements:

7a7960a

- adds line and column numbers to tests - warn on cases where argument is a spread element, - use getCommentsInside instead of regex - fix example in doc

sharmilajesupaul force-pushed the shar--prefer-object-spread branch from 97bab19 to 7a7960a Compare May 7, 2018 20:52

use spread instead of apply

0a0e1b1

platinumazure requested changes May 10, 2018

View reviewed changes

Check if the native Object is being overwritten, if it is, do not w…

751774d

…arn. Bug fix to ensure that an we're warning on an `Object.assign` for the literal case.

make messages consistent

afcacaa

platinumazure approved these changes May 11, 2018

View reviewed changes

not-an-aardvark reviewed May 11, 2018

View reviewed changes

ilyavolodin approved these changes May 11, 2018

View reviewed changes

ilyavolodin merged commit 1a6b399 into eslint:master May 11, 2018

mysticatea mentioned this pull request Jun 12, 2018

Rule request: prefer-object-spread #7230

Closed

eslint-deprecated bot locked and limited conversation to collaborators Nov 8, 2018

eslint-deprecated bot added the archived due to age This issue has been archived; please open a new issue for any further discussion label Nov 8, 2018


		When Object.assign is called using an object literal the first argument, this rule requires using the object spread syntax instead. This rule also warns on cases where an `Object.assign` call is made using a single argument that is an object literal, in this case, the `Object.assign` call is not needed.

		Please note: This rule can only be used when using an `ecmaVersion` of 2018 or higher, 9 or higher, or when using an `ecmaVersion` of 2015-2017 or 5-8 with the `experimentalObjectRestSpread` parser option enabled.

		@@ -0,0 +1,47 @@
		# Prefer use of an object spread over `Object.assign` (prefer-object-spread)

		When Object.assign is called using an object literal the first argument, this rule requires using the object spread syntax instead. This rule also warns on cases where an `Object.assign` call is made using a single argument that is an object literal, in this case, the `Object.assign` call is not needed.


		## Rule Details

		The following patterns are considered errors:

New: Adds prefer-object-spread rule (refs: #7230) #9955

New: Adds prefer-object-spread rule (refs: #7230) #9955

Conversation

sharmilajesupaul commented Feb 6, 2018 • edited

mysticatea left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sharmilajesupaul commented Feb 8, 2018

platinumazure commented Mar 22, 2018

sharmilajesupaul commented Mar 22, 2018

sharmilajesupaul commented Mar 23, 2018

platinumazure left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sharmilajesupaul commented Apr 13, 2018

ljharb left a comment

Choose a reason for hiding this comment

platinumazure left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sharmilajesupaul commented May 7, 2018 • edited

platinumazure left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sharmilajesupaul commented May 11, 2018

not-an-aardvark left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ljharb May 11, 2018 • edited

Choose a reason for hiding this comment

sharmilajesupaul commented Feb 6, 2018 •

edited

sharmilajesupaul commented May 7, 2018 •

edited

ljharb May 11, 2018 •

edited