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
Release proposal: standard v6 #399
Comments
\o/ |
✨ |
Merged the |
Going to try to get a beta release out on npm tomorrow. |
Changelog here: https://github.com/feross/standard/blob/master/CHANGELOG.md#600---2016-02-05 |
Standard is by far one of my favorite projects and I think it has really helped to improve the code quality in the JavaScript ecosystem. @feross I thank you for all of your hard work put into it. With that being said, I'm concerned that enabling standard to be configurable https://github.com/feross/standard/blob/master/CHANGELOG.md#expose-eslint-configuration-via-command-line-options-and-packagejson was a mistake. See https://github.com/feross/standard#can-you-make-rule-x-configurable:
I understand that we as developers need to evolve projects, take risks, listen to feedback, and iterate. However, this change feels antithetical to what standard stood for and what made it great. It seems entirely possible that I'm misunderstanding these changes or the importance of these changes and what they entail. My fear now is that I'll open up a @feross I respect and understand that I will definitely upgrade to Standard v6, continue to use and promote Standard, I just wanted to share this perspective. Thanks again for your hard work on this! |
Crap, I fully missed this - I was moving cities the last couple of days and somewhere this slipped. I agree with @jprichardson, I feel like this can be, and thus will be abused fully {
"standard": {
"rules": {
"semi": [2, "always"]
}
}
} If someone does the above, then saying that a project uses I kind of like being grumpy old farts that curate the one way to do things and if you don't like it shoo and configure your own. This doesn't feel right to me. |
agree with last two comments. leave it up to other modules to add On Saturday, February 6, 2016, Yoshua Wuyts notifications@github.com
Sent from my phone |
Thanks for the feedback guys. Better late than never, I suppose. This whole thing got me thinking about why people like
I originally made Adding a way for the super-obsessed to set an eslint plugin for whatever flavor-of-the-week JS thing they're using doesn't really affect my use case (reason 1). But it definitely affects reason 2, and makes "this project uses standard" mean way less. And that's not cool. I think ya'll are right. I done flubbed it up. There were issues about this in #386, #367, and #371, for So, just to recap. The reason for adding The reason for adding The reason for adding So, I'm 👍 to doing a quick v7 release to remove |
Could folks please chime in with feedback on the standard v7 release proposal: #404 |
IMHO a release that removes But otherwise amazing work on pumping out |
😜 |
+1 for keeping |
sounds cool. if anyone disagrees, they're always free to drop down to eslint + eslint-config-standard. |
At which point, the intention is clear as day and they're not using |
I just want to chime in this quickly as I've recently switched our project to Standard. I believe Standard is great if you are starting a project from scratch. But moving an existing codebase to it, it gets daunting as you will instantly get thousands of errors from the get go. Nobody wants to spend their days/weeks fixing lint errors (and nobody wants to fix these errors blindly either). This is where rules/globals/env really help as it helped me move from one class of errors to another one and making small wins in the process. Also, some of Standard's defaults are debatable within a team setting (e.g. semi and indentation level) and something that probably would slow a team down if introduced straightaway without some discussion. Again this is where 'rules' help as I can introduce these features slowly over time to the team without any friction or useless debates about style. I hope that sheds some light on some of the use-cases of rules, at least. globals - not everyone uses a module bundler and not all projects are in the npm registry, so globals help there. Cheers. |
I'm with @rstacruz on this keep standard strict. You can always customize with eslint + eslint-config-standard if you want a non-standard, standard (see how silly that sounds 😜). Anyway, all the good feels: https://twitter.com/HenrikJoreteg/status/697294740480352256 |
The goal of this release is to make
standard
faster to install, and simpler to use.standard-format
(Move standard --format into a separate module #340) (Remove standard-format. fixes #340 #397)standard
no longer assumes that JSX === React, so users can use alternatives likevirtual-dom
ordeku
.eslint-config-standard-jsx
instead ofeslint-config-standard-react
now.package.json
"standard" property__dirname
/__filename
string concatenation (Disallow string concatenation when using __dirname and __filename (no-path-concat) #403) (no-path-concat) [5%]new Promise()
is instantiated with the parameter namesresolve
,reject
(Force promise arguments name #282) (promise/param-names) [1%]*
inyield * something
(Difference infunction *
vsyield*
#335) (yield-star-spacing) [0%]parseInt()
radix rule because ES5 fixes this issue (is requiring Radix really necessary? #384) (radix) [0%]no-unexpected-multiline
false positive (eslint 2.0.0) eslint/eslint#5148) Fixed with PR 👍no-return-assign
behavior changed with arrow functions (no-return-assign
behavior changed with arrow functions eslint/eslint#5150) - RELEASED ANYWAY, NOTED UNDER "KNOWN ISSUES"The text was updated successfully, but these errors were encountered: