-
Notifications
You must be signed in to change notification settings - Fork 367
Upgrade eslint & config to latest #1179
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -6,6 +6,7 @@ | |
| // This test written in mocha+should.js | ||
| 'use strict'; | ||
|
|
||
| /* global getSchema:false, connectorCapabilities:false */ | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We should fix (ie. not use) these globals at some point. ;) That is outside the scope of this PR though.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree with both! Should we create an issue to keep track of this work? I am not sure if this problem important enough, there is no point in creating issues that nobody will work for months.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I believe it is important to keep our house as clean as possible and as soon as possible. We should not delay these minor issues for months IMO, but I'll leave that decision up to @ritch. Issue created at #1186 and assigned to @siddhipai |
||
| var should = require('./init.js'); | ||
| var async = require('async'); | ||
| var db, User; | ||
|
|
||
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.
Why not cb? I still prefer
cbovercallbackunless we've decided to do this all over the place.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.
@bajtos @superkhau either one is fine with me; consistency is what I would follow... I did a quick search in
lib/connectors/memory.jsand it seems most of the methods usecallback, so I would personally go forcallbackin this case; however I agree if I had the option with not lots ofcallbacks in the file, I would go forcbrather thancallbackbut it is a nitpick.@superkhau this one actually was a bug since there was no
cbin this method and that's why @bajtos changed it tocallback.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.
I'm also fine with either -- I would just like some consistency in our codebase instead of both.
Bug makes sense, but I would like the bugfix in a seperate commit at least so we know its unrelated to the ESLint fixes.
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.
In this patch, I am fixing undefined
cbto the correctcallback. Let's keep the discussion and (possibly) the refactoring out of scope of this pull request please.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.
It's a nitpick anyways, 2 commits (one for bug and one for the eslint changes) would've been better for the reviewer to determine WHY the cb/callback thing was changed since the bugfix is not a requirement of ESLint since this PR was for ESLint changes. I'm not saying make a separate PR, just another commit on top of the current changes.