-
Notifications
You must be signed in to change notification settings - Fork 664
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
Migrate to ESLint #361
Comments
My ideal {
"extends": "airbnb",
"rules": {
"func-names": [0],
"max-len": [2, 80],
"new-cap": [0],
"no-case-declarations": [2],
"no-confusing-arrow": [0],
"no-else-return": [0],
"no-multi-spaces": [0],
"no-param-reassign": [0],
"no-shadow": [0],
"no-use-before-define": [0],
"prefer-template": [0],
"space-before-function-paren": [2, "never"],
"strict": [2, "global"]
}
} |
Yes! I support this 100%. |
I like this a lot too (and thanks for the great link to the airbnb code). One thing that the new class system proposal would run afoul of is the |
Looks great. I like the final I don't know what all the options mean, but I'm happy to look through them in detail. (E.g., I used to care about 80-char line lengths, but it's a bit of an uphill battle, and I'm not sure if there's any value in it anymore.) |
Initial PR with four files here: #369 |
I think it's probably worth doing all the automatic steps at once. Here's a branch (continuing off of the previous PR) which shows the codebase after running every file through After the automatic steps, we're at 892 problems. Then I disabled the |
540 problems sounds great to deal with! Should we mark pull requests to go into that branch instead for now? I'd also be in favor of dropping 80 characters or at least moving to something more like 100 or 130. I prefer not to split quoted strings/error messages, even if it goes over the limit, so that they can be found in a search on the error message. (I.e., L('Massive Error in the ' + |
@mscuthbert Agreed. My earlier comment about the config is out of date. Following @0xfe's comment I bumped it up to 100. And I disabled a couple not-so-important rules to make the migration easier. Also, those split strings are usually great candidates for conversion to ES6 template strings. On the branch I just posted, the config file looks like this: {
"extends": "airbnb-base",
"root": true,
"rules": {
"max-len": [2, 100],
"camelcase": [0],
"no-case-declarations": [2],
"no-confusing-arrow": [0],
"new-cap": [0],
"no-else-return": [0],
"no-multi-spaces": [0],
"no-param-reassign": [0],
"no-shadow": [0],
"no-use-before-define": [0],
"quote-props": [0],
"prefer-template": [0],
"space-before-function-paren": [2, "never"],
"strict": [2, "global"]
}
} I'm happy to accept PRs to that branch. @0xfe do you have a preference on how we go about this? |
Also, worth noting that I've been reformatting errors to look like this: // If it fits on one line...
if (!this.accidental) {
throw new Vex.RERR('ArgumentError', `Unknown accidental type: ${type}`);
}
// If it's a little too long...
if (!this.accidental) {
throw new Vex.RERR(
'ArgumentError', `Unknown accidental type: ${type}. Extra stuff here to make the line longer.`
);
}
// if it's way too long
if (!this.accidental) {
throw new Vex.RERR(
'ArgumentError',
`Unknown accidental type: ${type}. Extra stuff here to make the line longer. And even longer!`
);
} |
Updated the wiki, added a todo list of all files, and checked off those which are complete. |
Super basic question, but how to we get the list of errors for each file? Simply run grunt? or... |
Ah, of course I forgot the basic bits. You have two options: Running Or you can run eslint independently of grunt:
|
Sending PRs to Silverwolf's branch sounds good. Cyril can you send me PRs every time you have a few files ready. It's easier to review in smaller batches (and also to debug if things go wrong.) |
Yep that sounds good! |
Although I would suggest we do all the safe automatic transforms at once across the codebase in one PR. And from there go a few files at a time. |
EDIT: Ok. Looks like we can do it with master then! So, am I reading this right that I can do this?
|
Yes! 👍 I guess this issue is the best place to claim your files. First come first serve. :-) |
Just FYI that I've completed these already: accidental.js |
I'll have a go at the following (if this causes too much insanity with merges, please let me know): annotation.js EDIT: Done in #375 |
Note that in #374 I've removed the restriction on the |
Just completed strokes.js Edit: Only 360 errors remain! |
Just opened a PR where I've just taken care of: frethandfinger.js EDITS: |
Finished! EDIT: Branch here https://github.com/Silverwolf90/vexflow/tree/eslint-complete |
\o/ You're a superstar, Cyril! Just merged everything! You deserve the honors of closing this issue. :-p |
Awesome! And thank you! Closing. |
Whooooooo! Hoooooooo! :-) |
Wow -- bravo! |
As we start to move over to ES6, I wanted to propose using ESLint over JSHint.
Reasons:
vexflow
specific set of eslint rules that suggest best practices, or warn of improper usage.eslint --fix
I personally use the airbnb style guide's
eslint-config
, with some tweaks. For the most part it's a great starting place, but I find it overly strict in some cases. But in general, VexFlow would benefit significantly from having stricter linting rules.The text was updated successfully, but these errors were encountered: