-
Notifications
You must be signed in to change notification settings - Fork 63
Conversation
.eslintrc.json
Outdated
@@ -0,0 +1,208 @@ | |||
{ | |||
"parserOptions": { | |||
"ecmaVersion": 2020, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if you're supporting node 10, you'll want to use 2018, i think?
.eslintrc.json
Outdated
"ecmaFeatures": { | ||
"jsx": true | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does arborist use jsx? if not, you won't want to allow jsx to parse successfully.
.eslintrc.json
Outdated
"ecmaFeatures": { | ||
"jsx": true | ||
}, | ||
"sourceType": "module" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is only correct if you're using import/export; i'm pretty sure you want "script" here for arborist since you're not using native ESM.
We have more people contributing to this library now, so adding some automated consistency is looking more and more important. Also, this found a few unused variables, which highlighted a bug, albeit a harmless one: a timer string was being created, but then no timer being attached to Shrinkwrap loading. (That's why the reify snapshot is updated.) Some other light refactoring was done in a few places to get eslint to produce a reasonably readable output, and I think mostly for the improvement of readability. I don't 100% agree with every choice the linter is making here. Specifically, I prefer using {} around single-line blocks in some cases, especially loops, but they are omitted most of the time, so that's the way I set the config. Consistency is good though, and this will help us maintain it. Linting is set up as a posttest operation, so we can catch things without having it stubbornly refuse to even run tests until it's all sparkling.
@ljharb Thanks! Updated with your suggestions. I'd just copied what was in the CLI, which was copied from what ships in standard. |
We have more people contributing to this library now, so adding some
automated consistency is looking more and more important.
Also, this found a few unused variables, which highlighted a bug, albeit
a harmless one: a timer string was being created, but then no timer
being attached to Shrinkwrap loading. (That's why the reify snapshot is
updated.) Some other light refactoring was done in a few places to get
eslint to produce a reasonably readable output, and I think mostly for
the improvement of readability.
I don't 100% agree with every choice the linter is making here.
Specifically, I prefer using {} around single-line blocks in some cases,
especially loops, but they are omitted most of the time, so that's the
way I set the config. Consistency is good though, and this will help us
maintain it.
Linting is set up as a posttest operation, so we can catch things
without having it stubbornly refuse to even run tests until it's all
sparkling.
References