tools: switch from closure-linter to eslint #1539

yosuke-furukawa · 2015-04-27T19:21:58Z

As we discussed before #1253, I would like to propose to switch from closure-linter to other ES6 friendly linter.

Because closure-linter does not recognize template string literals, class syntax and arrow functions, etc...
I have a motivation to improve our code to ES6. closure linter may be a blocker.

Currently, I just switched the closure linter to eslint and jscs.
And I fixed eslint errors in our existing JS files without test folder.

If you have any concerns, please tell me.

Reviewer: @chrisdickinson
Reviewer: @silverwind

chrisdickinson · 2015-04-27T19:24:56Z

lib/_debugger.js

@@ -65,15 +65,13 @@ function Protocol() {
 }
 exports.Protocol = Protocol;

-


Style guide is to put two blank newlines between top-level statements.

I don't think the current linter enforces this, but if possible, I'd loosen that rule to permit double empty lines in jscs. Otherwise, I'd be fine if we drop that requirement.

thanks. two blank lines between functions is useful.

chrisdickinson · 2015-04-27T19:52:40Z

Would it be possible to re-cut these commits into commits per-lib-file, one commit removing gjslint, one commit adding eslint, and one commit adding the eslint config? My computer can't handle showing the diff right now.

silverwind · 2015-04-27T20:37:01Z

lib/child_process.js

@@ -394,12 +393,12 @@ function setupChannel(target, channel) {
      } else if (handle instanceof UDP) {
        message.type = 'dgram.Native';
      } else {
-        throw new TypeError("This handle type can't be sent");
+        throw new TypeError(`This handle type can't be sent`);


I'd allow this through "quotes": [2, "single", "avoid-escape"]

silverwind · 2015-04-27T21:13:24Z

I think generally we should keep unused args where possible, if just for future reference. I'd suggest

"no-unused-vars": [2, {"vars": "all", "args": "none"}]

For the DTRACE vars, I think we could create a custom rule. I'd be vary of template strings in performance-critical parts, I think they aren't optimized as well as regular string concatenation.

Overall I like it as a first step, we can use this as a base to further tighten the rules later.

yosuke-furukawa · 2015-04-29T05:54:01Z

@chrisdickinson @silverwind Thanks for your review.
I fixes the following points.

separates my commits for @chrisdickinson suggestion (tools: switch from closure-linter to eslint #1539 (comment))
Add rules for no-unused-vars and reset the unused vars. Thanks @silverwind

But I have not fixed the two blank newlines between top-level statements.

I would like to discuss the rules.

two blank newlines

Unfortunately, I could not find the "two blank newlines between top-level statements" on current jscs rules. And our current gjslint does not permit the rule.

If we don't have the interest to permit the rule, we set disallowMultipleLineBreaks: null in .jscsrc.
But current google javascript style guide in jscs has the rule (https://github.com/jscs-dev/node-jscs/blob/master/presets/google.json#L62) .

IMO, I would like to change the rule "two blank newlines" to "single newline". If so, no need to change current commits. :)

silverwind · 2015-04-29T06:01:22Z

I'd be fine with single newline, I love compact code.

yosuke-furukawa · 2015-04-29T06:21:47Z

@silverwind Thanks!

And we also discuss about the ES6 rules.
current rule:

"ecmaFeatures": {
    "blockBindings": true,
    "templateStrings": true,
    "octalLiterals": true,
    "binaryLiterals": true
},

blockBindings and octalLiterals and binaryLiterals are already used in current code.
I would like to add templateStrings. templateStrings does not have an impact on performance.
That is the performance result. #691 (comment)

And I just use templateStrings on some exception messages.

silverwind · 2015-04-29T15:09:57Z

Would like a quick TC consensus whether we should drop or keep the 'two empty lines' rule between top-level 'blocks' in JavaScript files.

Me and @yosuke-furukawa would like to drop that rule.

Fishrock123 · 2015-04-29T17:32:15Z

lib/repl.js

@@ -571,7 +567,8 @@ REPLServer.prototype.complete = function(line, callback) {
            this.context.constructor &&
            this.context.constructor.name === 'Context') {
          var contextProto = this.context;
-          while (contextProto = Object.getPrototypeOf(contextProto)) {
+          while (
+            (contextProto = Object.getPrototypeOf(contextProto)) === true) {


() === true is unnecesary

IMO, we should use condition in conditional sentences.
I am happy if linter checks the following bug.

if (a = 'test') { // a == 'test' is really needed code // ... }

Hmm, while assignment inside a condition is a common error, I like the conciseness of how it was before.

The common practice for those assignments is to write them like this:

// good code if ((a = 'test')) { // ... }

So additional parentheses are a signal to a linter that a developer is intended to write this code as is.

But this is very verbose and completely unnecessary:

// don't do this if ((a = 'test') === true) { // ... }

Fishrock123 · 2015-04-29T17:37:48Z

I am +1 on moving to a more modern linter.

I am very -1 on the current state of style changes. This is currently far too strict.

(Also more than one-line-spacing shouldn't matter to the linter..)

trevnorris · 2015-04-29T20:25:50Z

lib/_debugger.js

 Protocol.prototype._newRes = function(raw) {
-  this.res = { raw: raw || '', headers: {} };
+  this.res = {raw: raw || '', headers: {}};


I feel like it's more common style to leave blank space on { }. Could we leave that?

Agree, looks subjectively cleaner with the spaces.

Agree. We should change disallowSpacesInsideObjectBrackets on .jscsrc .

rlidwka · 2015-04-30T16:35:40Z

I am very -1 on the current state of style changes. This is currently far too strict.

Same thought here. This PR is about changing linter, not changing code style.

If eslint/jscs can't validate the existing code style, it is not a good reason to change the existing code (you know, git blame worsening and stuff). In that case maybe we should stay on gjslint instead.

I don't have much of experience with jscs, but I could say a lot about eslint. It is good, but it is unacceptably opinionated by default. Please use --reset flag and enable only those rules that you need here. In particular, if we have empty blocks (and those are reasonable to have), don't enable the rule that complains about them.

silverwind · 2015-04-30T16:47:32Z

Agreed, we should first get the linter in with the minimal necessary changes. Further changes to the rules can be discussed in seperate PRs.

rlidwka · 2015-04-30T16:53:17Z

Maybe enable only a minimal subset of eslint rules first (I personally use only 11 rules that detect most of the errors). After that we could discuss each and every rule you want to enable on top of that in separate PRs.

yosuke-furukawa · 2015-04-30T17:10:56Z

Agreed. I should separate the eslint/jscs change request and code style change request.
code style discussion is not single topic, I will recut this pull request.
Thank you for your suggestion.

yosuke-furukawa · 2015-05-01T13:40:10Z

@chrisdickinson @silverwind @Fishrock123 @trevnorris @rlidwka

I loosen the eslint and jscs rules and I applied the minimum rule sets.
So current rules don't permit double lines / yoda condition / assignment in conditional statement.

I just use semicolon, comma, comment rules.

please see the following eslint / jscs rules.

LGTY????

rlidwka · 2015-05-01T13:48:33Z

I don't like that list of disabled rules in eslint (https://github.com/yosuke-furukawa/io.js/commit/4a9f61a4956a5032fd0f2d0177ecc6f11fc91832). It's not clear which rules we do use. And also if eslint removes one of the disabled rules in the future, this config will throw an error.

Maybe use --reset and explicitly enable all the rules we want?

I'm not familiar with jscs to say anything, but I heard eslint already has most of jscs rules. What do we need two separate linters for?

silverwind · 2015-05-06T16:15:28Z

@yosuke-furukawa can you rebase please? The recent revert of url causes the patch to fail. I expect to LGTM this shortly.

yosuke-furukawa · 2015-05-07T16:44:03Z

@silverwind Done. But If this pull request merged, I will re-rebase them. #1650

silverwind · 2015-05-07T16:59:49Z

LGTM

Fishrock123 · 2015-05-07T17:08:03Z

I'm ok with these style fixes.

@iojs/collaborators ptal

indutny · 2015-05-07T17:11:50Z

I'm fine with this! LGTM

jbergstroem · 2015-05-07T21:53:44Z

LGTM

trevnorris · 2015-05-08T15:30:10Z

Great job keeping it as close to how things are currently done. LGTM

yosuke-furukawa · 2015-05-08T17:55:24Z

Thank you for your review! I would like to push the changes.
But, current commit logs are a little messy.

I will squash my commits to 3 commits like:

Switch closure linter to eslint
Add eslint settings
Fix styles on library

Is that OK??? Does anyone have some suggestions ?

silverwind · 2015-05-08T17:57:24Z

I'd do two commits, one for the whole of eslint, including settings, the other for style fixes.

yosuke-furukawa · 2015-05-08T18:08:49Z

@silverwind No problem!

PR-URL: #1539 Fixes: #1253 Reviewed-By: Jeremiah Senkpiel <[email protected]> Reviewed-By: Trevor Norris <[email protected]> Reviewed-By: Roman Reiss <[email protected]> Reviewed-By: Chris Dickinson <[email protected]> Reviewed-By: Johan Bergström <[email protected]> Reviewed-By: Fedor Indutny <[email protected]>

yosuke-furukawa · 2015-05-09T03:18:46Z

Thank you all reviewer, Landed in f9dd34d , 19ffb5c .

PR-URL: nodejs#1539 Fixes: nodejs#1253 Reviewed-By: Jeremiah Senkpiel <[email protected]> Reviewed-By: Trevor Norris <[email protected]> Reviewed-By: Roman Reiss <[email protected]> Reviewed-By: Chris Dickinson <[email protected]> Reviewed-By: Johan Bergström <[email protected]> Reviewed-By: Fedor Indutny <[email protected]>

		@@ -65,15 +65,13 @@ function Protocol() {
		}
		exports.Protocol = Protocol;

tools: switch from closure-linter to eslint #1539

tools: switch from closure-linter to eslint #1539

Conversation

yosuke-furukawa commented Apr 27, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chrisdickinson commented Apr 27, 2015

Choose a reason for hiding this comment

silverwind commented Apr 27, 2015

yosuke-furukawa commented Apr 29, 2015

two blank newlines

silverwind commented Apr 29, 2015

yosuke-furukawa commented Apr 29, 2015

silverwind commented Apr 29, 2015

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

Fishrock123 commented Apr 29, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rlidwka commented Apr 30, 2015

silverwind commented Apr 30, 2015

rlidwka commented Apr 30, 2015

yosuke-furukawa commented Apr 30, 2015

yosuke-furukawa commented May 1, 2015

rlidwka commented May 1, 2015

silverwind commented May 6, 2015

yosuke-furukawa commented May 7, 2015

silverwind commented May 7, 2015

Fishrock123 commented May 7, 2015

indutny commented May 7, 2015

jbergstroem commented May 7, 2015

trevnorris commented May 8, 2015

yosuke-furukawa commented May 8, 2015

silverwind commented May 8, 2015

yosuke-furukawa commented May 8, 2015

yosuke-furukawa commented May 9, 2015