-
Notifications
You must be signed in to change notification settings - Fork 15
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
Make a few exceptions to the standard rules #2
Comments
@zeke So we don't have to fork things crazily. Couldn't we "hack" in eslint disable comments to the JS blocks we are parsing. I.e. We have a code block const disabledRules = ['no-undef', 'no-unused-vars', 'no-lone-blocks', 'no-labels'];
let block = getCodeBlockThing();
block = `
/* eslint-disable ${disabledRules.join(', ')} */
` + block;
standard.lintText(block) This is untested, just an idea 😄 |
I didn't see this until now because you misspelled my name, @zeke 😜 Disabling these rules makes @MarshallOfSound's suggesting is the best solution IMO. It's easiest and easy to maintain -- will have the exact same rules, dependency versions, etc. as the latest stable Another option, but less ideal, is to extend You can make a {
"extends": ["standard", "standard-jsx"],
"rules": {
"no-undef": 0,
"no-unused-vars": 0
}
} Install all the One big downside is now it's your responsibility to ensure that the package versions are kept up-to-date and match what's in |
Doh! I do know how to spell it. I blame my fingers. 🖖 |
Thanks for the help, @MarshallOfSound and @feross! |
The
standard
linter has a few rules that feel restrictive when applied to javascript blocks in markdown files. While standardizing electron's docs, these are the rules I came across that I think we could do without:Disallow Undeclared Variables (no-undef)
Disallow Unused Variables (no-unused-vars)
Disallow Unnecessary Nested Blocks (no-lone-blocks, no-labels)
Example electron/electron#6748
How?
I think the way to accomplish this is by forking eslint-config-standard, then using standard-engine to load it. We can use the numerous standard forks for reference.
@ferros, @Flet: If we only wish to deviate very slightly from standard's defaults, is there a way to codify the differences in a
package.json
stanza? Or is standard-engine with a custom eslint package the way to go?cc @kevinsawicki @jlord @zcbenz
The text was updated successfully, but these errors were encountered: