-
Notifications
You must be signed in to change notification settings - Fork 45
Add nodestyle and lint code #45
base: main
Are you sure you want to change the base?
Conversation
This looks good and I think we should merge it in but I have one major issue and one minor one. Secondly, and more as a proper review comment, is node-style assumed to be globally installed or does it need to be added as a dependency somewhere? |
package.json
Outdated
"test": "tap test/test*.js" | ||
}, | ||
"bugs": { | ||
"url": "https://github.com/nodejs/nodereport/issues" | ||
}, | ||
"devDependencies": { | ||
"node-style": "^1.1.0", |
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.
@hhellyer node-style is added as a devDependency here (i.e. it won't show up if you npm i node-report
, but it will show up if you cd node-report && npm i
.
@geek I see that you're a maintainer for Incidentally we're currently looking at linting in nodejs/citgm#334, so I'm interested in the pros and cons. cc/ @gdams |
@gibfahn the rules for node-style align with those used for node core. The benefit is consistency and alignment across projects. |
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.
Based on the assertion that these are now the same as used for node core, LGTM
I'm struggling to understand why if we want to be consistent with node core why we wouldn't want to use |
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.
Looking deeper sounds like we need more discussion. What I'm thinking is that we really just want something which is the same as in node core, if we need something more then we should explain the case for that. So as George mentioned why would we not just use the nodejs/node's config.
I think #446 is a better approach. The tool being added here may be a nice thing for projects that are not part of If nodejs wanted to factor its eslint rules out, eslint already support this easily, https://www.npmjs.com/package/eslint-config-strongloop is an example of what we did for strongloop, it would be easy to do for node's tools, too - though node itself heavily favours "vendoring" its dependencies directly so that the repo is self-contained. |
Just tried building this PR on Node.js 4.7.2 and got this:
|
@richardlau eslint version? We can raise as a bug: https://github.com/eslint/eslint/blob/master/package.json#L120 |
Closes #44