-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # 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: