tools: eslint object curly spacing

[sebdeckers]

As per suggestion by @jasnell, this is a de-facto house style. Enabling this rule makes it de-jure.

Not sure how the commit message guideline would make me label this commit, so I've left it as tools: even though the (hopefully inert) lint fixes touch other areas.

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes (@sebdeckers: works on my machine 😅)
• commit message follows commit guidelines (as per comment below)

Affected core subsystem(s)

tools

[refack]

Not sure how the commit message guideline would make me label this commit, so I've left it as tools: even though the (hopefully inert) lint fixes touch other areas.

IMHO tools: is the right prefix

[mscdex]

We should leave out changes to upstream packages (e.g. files in tools/icu).

[refack]

No need for " in yaml

I need to take another look

[refack]

/cc @nodejs/release

[sebdeckers]

Thanks for the super quick feedback! ❤️
@mscdex I've undone the change and added tools/icu to .eslintignore
@refack cleaned up the quotes

Q: Should I squash the commits, either while pushing changes in response to reviews, or once the changes have been approved?

[refack]

Q: Should I squash the commits, either while pushing changes in response to reviews, or once the changes have been approved?

Just adding commits is the best way for us to review. Commits will probably be squashed while landing.
Conflicts might arise before this PR lands, in that case you'll probably need to rebase and fix the conflicts.

[Trott]

You can reduce the churn slightly and conform more closely to the house style by doing this instead:

  object-curly-spacing: [error, always, {objectsInObjects: false}]

That flags 2144 problems in the current code base, instead of the 2183 flagged with the PR as it is. That's not a huge reduction, but every little bit helps to make backporting less awful.

[sebdeckers]

99% of these changes were made using eslint --fix automatically. Except for ~30 cases where the insertion of spaces then caused the line to grow longer than 80 characters, which I cleaned up manually following my own stylistic judgement and ensuring eslint passes.

[gibfahn]

In general it's useful to do the automatic ones as one commit, and then the manual ones as a separate one. They'll get squashed on landing, but it means people can review the ones that weren't just an eslint --fix (which are probably the more interesting ones).

[mscdex]

Perhaps we should also add 'deps/' to .eslintignore (assuming that will match everything in deps).

[Trott]

Perhaps we should also add 'deps/' to .eslintignore (assuming that will match everything in deps).

We don't run ESLint on the deps directory so there's no need to ignore files in it. We explicitly run it on benchmark, doc, lib, tools, and test directories only.

[vsemozhetbyt]

If the rule remains as it is now in the main .eslintrc.yaml, you can delete it from the doc/.eslintrc.yaml.

[sebdeckers]

@vsemozhetbyt Done. Thank you for the suggestion!

[vsemozhetbyt]

LGTM if full CI is green when unblocked (in case I've missed something).

[refack]

I'm thinking the main commit should be split to 5 (since each directory have different backporting concern):

1. /benchmark/
2. /lib/
3. /test/
4. /tools/
5. .eslintrc.yamls

Although this should be a 0 semantic change, and could be backported as a whole.
But @nodejs/release should give the final word

[Trott]

I'm thinking the main commit should be split to 5

I'm not saying it's better or worse, but in the past, we've often done it as two commits: One for the code updates, and one for enabling the rule in eslintrc.

[gibfahn]

I'm thinking the main commit should be split to 5 (since each directory have different backporting concern):

I think as they're just using eslint --fix they'll just be backported by backporting the rule and then running eslint --fix again, so in this specific case I don't think it's necessary.

[vsemozhetbyt]

CI: https://ci.nodejs.org/job/node-test-pull-request/9074/

[Trott]

@sebdeckers The name of this PR should say object curly spacing rather than template curly spacing. Or am I mistaken?

[evanlucas]

I think I'm -1 on this change. I wouldn't say the house style is to include spaces, especially if this requires 292 changes...

[sebdeckers]

@evanlucas I didn't mean for this change to be about bikeshedding eslint rules. "House style" was quoted from the referenced comment; not my words. As for the high change count, I'd argue that proves the need for this option to be set one way or another.

[TimothyGu]

I'd like to standardize around array spacing too. The preferred style, I believe, is to not add spaces inside brackets.

[refack]

I think I'm -1 on this change. I wouldn't say the house style is to include spaces, especially if this requires 292 changes...

The other side of the argument — setting:

object-curly-spacing: [error, never]

results in 3646 errors in 517 files

[jasnell]

largely rubber stamp lgtm

[sebdeckers]

Rebased and delinted recent commits.

[vsemozhetbyt]

CI: https://ci.nodejs.org/job/node-test-pull-request/9286/

[vsemozhetbyt]

Linter fails:

test/parallel/test-fs-open-flags.js
  59:23  error  A space is required after '{'   object-curly-spacing
  59:70  error  A space is required before '}'  object-curly-spacing

test/parallel/test-internal-fs.js
  12:3   error  A space is required after '{'   object-curly-spacing
  12:59  error  A space is required before '}'  object-curly-spacing

[refack]

Landed in 6add5b3 bb29405

[refack]

Extra sanity test on master: https://ci.nodejs.org/job/node-test-commit-linuxone/7482/
Extra lint on master: https://ci.nodejs.org/job/node-test-linter/10672/

[addaleax]

@sebdeckers This doesn’t land cleanly on 8.x; if you can, please follow the guide and raise a backport PR.

[MylesBorins]

Since this touches so many files it would be really great to get a backport to v6.x to avoid future merge conflicts. Please follow this guide and raise a backport PR.