Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

test,tools: refactor custom ESLint for readability #21134

Closed
wants to merge 1 commit into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
38 changes: 13 additions & 25 deletions test/parallel/test-eslint-lowercase-name-for-primitive.js
Original file line number Diff line number Diff line change
Expand Up @@ -7,45 +7,33 @@ common.skipIfEslintMissing();
const RuleTester = require('../../tools/node_modules/eslint').RuleTester;
const rule = require('../../tools/eslint-rules/lowercase-name-for-primitive');

const valid = [
'string',
'number',
'boolean',
'null',
'undefined'
];

new RuleTester().run('lowercase-name-for-primitive', rule, {
valid: [
'new errors.TypeError("ERR_INVALID_ARG_TYPE", "a", ["string", "number"])',
...valid.map((name) =>
`new errors.TypeError("ERR_INVALID_ARG_TYPE", "name", "${name}")`
)
'new errors.TypeError("ERR_INVALID_ARG_TYPE", "name", "string")',
'new errors.TypeError("ERR_INVALID_ARG_TYPE", "name", "number")',
'new errors.TypeError("ERR_INVALID_ARG_TYPE", "name", "boolean")',
'new errors.TypeError("ERR_INVALID_ARG_TYPE", "name", "null")',
'new errors.TypeError("ERR_INVALID_ARG_TYPE", "name", "undefined")',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we moving to trailing commas?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we moving to trailing commas?

@lpinca We use both styles in the code base. I would never block or even nit anyone else's PRs about it, but yes, I try to add trailing-commas when the opportunity presents itself.

FWIW, right now on master, if we change the comma-dangle rule to this…:

    'comma-dangle': ['error', {
      arrays: 'always-multiline',
      objects: 'only-multiline',
    }],

…we get 689 lines to change across 367 files. That's not something I'd want to do in a single comma-dangle PR but also something that seems achievable over enough time. (We've done it for other rules.)

In #19133, it seemed agreed that this approach (change when you can if you're already in there for other reasons) was a reasonable approach.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not suggesting to enable the rule or blocking this for such a nuance, I was only only interested to know if any decision was made about that. In a recent PR discussion (I'll try to find it and link here) some collaborators, me included, were not very happy with trailing commas.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lpinca I suspect you mean the voting on this comment: #20703 (comment)

You, tniessen, and cjihrig went for "no trailing comma".

A little later on, bnoordhuis, targos, and mmarchini seemed to be in favor of it (definitely bnoordhuis, and inferring the other two from the GitHub reactions on #20703 (comment)).

Dangling-comma vs. no-dangling-comma may finally be impossible for the project to resolve unlike the venerable tabs vs. spaces and semicolons vs. no-semicolons.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was only only interested to know if any decision was made about that.

In that case: Definitely not. No decision has been made.

],
invalid: [
{
code: 'new errors.TypeError(\'ERR_INVALID_ARG_TYPE\', \'a\', ' +
'\'Number\')',
code: "new errors.TypeError('ERR_INVALID_ARG_TYPE', 'a', 'Number')",
errors: [{ message: 'primitive should use lowercase: Number' }],
output: 'new errors.TypeError(\'ERR_INVALID_ARG_TYPE\', \'a\', ' +
'\'number\')'
output: "new errors.TypeError('ERR_INVALID_ARG_TYPE', 'a', 'number')",
},
{
code: 'new errors.TypeError(\'ERR_INVALID_ARG_TYPE\', \'a\', ' +
'\'STRING\')',
code: "new errors.TypeError('ERR_INVALID_ARG_TYPE', 'a', 'STRING')",
errors: [{ message: 'primitive should use lowercase: STRING' }],
output: 'new errors.TypeError(\'ERR_INVALID_ARG_TYPE\', \'a\', ' +
'\'string\')'
output: "new errors.TypeError('ERR_INVALID_ARG_TYPE', 'a', 'string')",
},
{
code: 'new errors.TypeError(\'ERR_INVALID_ARG_TYPE\', \'a\', ' +
'[\'String\', \'Number\']) ',
code: "new e.TypeError('ERR_INVALID_ARG_TYPE', a, ['String','Number'])",
errors: [
{ message: 'primitive should use lowercase: String' },
{ message: 'primitive should use lowercase: Number' }
{ message: 'primitive should use lowercase: Number' },
],
output: 'new errors.TypeError(\'ERR_INVALID_ARG_TYPE\', \'a\', ' +
'[\'string\', \'number\']) '
}
output: "new e.TypeError('ERR_INVALID_ARG_TYPE', a, ['string','number'])",
},
]
});
4 changes: 1 addition & 3 deletions tools/eslint-rules/lowercase-name-for-primitive.js
Original file line number Diff line number Diff line change
Expand Up @@ -12,9 +12,7 @@
const astSelector = 'NewExpression[callee.property.name="TypeError"]' +
'[arguments.0.value="ERR_INVALID_ARG_TYPE"]';

const primitives = [
'number', 'string', 'boolean', 'null', 'undefined'
];
const primitives = [ 'number', 'string', 'boolean', 'null', 'undefined' ];

module.exports = function(context) {
function checkNamesArgument(node) {
Expand Down