[RFR] Switch to ESlint #388

Merged
merged 2 commits into from Apr 2, 2015

Conversation

Projects
None yet
4 participants
@pascalduez
Member

pascalduez commented Mar 22, 2015

  • Waiting for babel/babel-eslint#31
  • space-before-function-parentheses or space-before-function-paren does not seem to work
  • A few fixes left
@valeriangalliat

This comment has been minimized.

Show comment
Hide comment
@valeriangalliat

valeriangalliat Mar 22, 2015

Member

Awesome work!

Feels really good to remove all these ignore comments.

Member

valeriangalliat commented Mar 22, 2015

Awesome work!

Feels really good to remove all these ignore comments.

@pascalduez

This comment has been minimized.

Show comment
Hide comment
@pascalduez

pascalduez Mar 22, 2015

Member

Plus it's driving out much more possible issues than JShint.

@valeriangalliat feel free to hack in if you see something.

Member

pascalduez commented Mar 22, 2015

Plus it's driving out much more possible issues than JShint.

@valeriangalliat feel free to hack in if you see something.

@HugoGiraudel

This comment has been minimized.

Show comment
Hide comment
@HugoGiraudel

HugoGiraudel Mar 22, 2015

Member

Terrific. Only the tests to fix before merging. :)

Member

HugoGiraudel commented Mar 22, 2015

Terrific. Only the tests to fix before merging. :)

@pascalduez

This comment has been minimized.

Show comment
Hide comment
@pascalduez

pascalduez Mar 22, 2015

Member

Something to discuss:

src/cli.js
  45:6  error  Don't use process.exit(); throw an error instead  no-process-exit
  48:4  error  Don't use process.exit(); throw an error instead  no-process-exit

http://eslint.org/docs/rules/no-process-exit.html

I guess we can mute this rule.

Member

pascalduez commented Mar 22, 2015

Something to discuss:

src/cli.js
  45:6  error  Don't use process.exit(); throw an error instead  no-process-exit
  48:4  error  Don't use process.exit(); throw an error instead  no-process-exit

http://eslint.org/docs/rules/no-process-exit.html

I guess we can mute this rule.

@HugoGiraudel

This comment has been minimized.

Show comment
Hide comment
@HugoGiraudel

HugoGiraudel Mar 22, 2015

Member

Any reason we do exit instead of throwing an error?

Member

HugoGiraudel commented Mar 22, 2015

Any reason we do exit instead of throwing an error?

@valeriangalliat

This comment has been minimized.

Show comment
Hide comment
@valeriangalliat

valeriangalliat Mar 22, 2015

Member

Any reason we do exit instead of throwing an error?

To control the exit code.

+1 to mute the rule, it's not meaningful in the CLI, it's only relevant inside the library code (and we don't exit from the library).

Member

valeriangalliat commented Mar 22, 2015

Any reason we do exit instead of throwing an error?

To control the exit code.

+1 to mute the rule, it's not meaningful in the CLI, it's only relevant inside the library code (and we don't exit from the library).

@valeriangalliat

This comment has been minimized.

Show comment
Hide comment
@valeriangalliat

valeriangalliat Mar 22, 2015

Member

searchForMatches is calling the isAnnotatedByHand function passed as a parameter. It don't uses the upper scope declared function (though the calling code is actually passing it this very function, see searchForMatches calls).

Member

valeriangalliat commented Mar 22, 2015

searchForMatches is calling the isAnnotatedByHand function passed as a parameter. It don't uses the upper scope declared function (though the calling code is actually passing it this very function, see searchForMatches calls).

@pascalduez

This comment has been minimized.

Show comment
Hide comment
@pascalduez

pascalduez Mar 22, 2015

Member

Yeah, I removed my comment, just realized the isAnnotatedByHand.bind(...)
Renaming the parameter into isAnnotatedByHandProxy

Member

pascalduez commented Mar 22, 2015

Yeah, I removed my comment, just realized the isAnnotatedByHand.bind(...)
Renaming the parameter into isAnnotatedByHandProxy

@coveralls

This comment has been minimized.

Show comment
Hide comment
@coveralls

coveralls Mar 22, 2015

Coverage Status

Coverage remained the same at 94.09% when pulling ab89646 on eslint into 81ec9e3 on develop.

Coverage Status

Coverage remained the same at 94.09% when pulling ab89646 on eslint into 81ec9e3 on develop.

@pascalduez pascalduez changed the title from [WIP] Switch to ESlint to [RFR] Switch to ESlint Mar 22, 2015

@pascalduez

This comment has been minimized.

Show comment
Hide comment
@pascalduez

pascalduez Mar 22, 2015

Member

So this is now Ready for review :-)

We are using all of ESlint default rules, overriding just the few ones we "don't agree" with.
There's also a couple of style rules added.
I personally like this approach.

Another option is not to use any base rules with --reset and set all the rules our self.

If you see something that should be added ?

Member

pascalduez commented Mar 22, 2015

So this is now Ready for review :-)

We are using all of ESlint default rules, overriding just the few ones we "don't agree" with.
There's also a couple of style rules added.
I personally like this approach.

Another option is not to use any base rules with --reset and set all the rules our self.

If you see something that should be added ?

@valeriangalliat

This comment has been minimized.

Show comment
Hide comment
@valeriangalliat

valeriangalliat Mar 22, 2015

Member

I like it as is, okay to merge. 👍

Member

valeriangalliat commented Mar 22, 2015

I like it as is, okay to merge. 👍

@coveralls

This comment has been minimized.

Show comment
Hide comment
@coveralls

coveralls Mar 22, 2015

Coverage Status

Coverage remained the same at 94.09% when pulling 1aaed23 on eslint into 81ec9e3 on develop.

Coverage Status

Coverage remained the same at 94.09% when pulling 1aaed23 on eslint into 81ec9e3 on develop.

@pascalduez

This comment has been minimized.

Show comment
Hide comment
@pascalduez

pascalduez Mar 28, 2015

Member

What about moving to adding a space between function declaration name and params.
Which brings us closer to standard

function whatever (foo, bar) { ... } 
Member

pascalduez commented Mar 28, 2015

What about moving to adding a space between function declaration name and params.
Which brings us closer to standard

function whatever (foo, bar) { ... } 
@valeriangalliat

This comment has been minimized.

Show comment
Hide comment
@valeriangalliat

valeriangalliat Mar 28, 2015

Member

I'm all for following standard. I'm also okay with semistandard which is basically like standard but with semicolons (and thus will be more friendly with our codebase).

Member

valeriangalliat commented Mar 28, 2015

I'm all for following standard. I'm also okay with semistandard which is basically like standard but with semicolons (and thus will be more friendly with our codebase).

@coveralls

This comment has been minimized.

Show comment
Hide comment
@coveralls

coveralls Apr 2, 2015

Coverage Status

Coverage remained the same at 94.09% when pulling b8c4746 on eslint into 81ec9e3 on develop.

Coverage Status

Coverage remained the same at 94.09% when pulling b8c4746 on eslint into 81ec9e3 on develop.

@coveralls

This comment has been minimized.

Show comment
Hide comment
@coveralls

coveralls Apr 2, 2015

Coverage Status

Coverage remained the same at 94.09% when pulling b8c4746 on eslint into 81ec9e3 on develop.

Coverage Status

Coverage remained the same at 94.09% when pulling b8c4746 on eslint into 81ec9e3 on develop.

pascalduez added a commit that referenced this pull request Apr 2, 2015

@pascalduez pascalduez merged commit 0d08922 into develop Apr 2, 2015

3 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details
coverage/coveralls Coverage remained the same at 94.09%
Details

@pascalduez pascalduez deleted the eslint branch Apr 2, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment