Release proposal: standard v8 #564
Comments
|
I'm happy to announce the immediate availability of a You try it out today by installing it: Cheers! 🎉 |
|
Hey collaborators! I have a favor to ask: Can you test out the Feedback would be great! @maxogden @mafintosh @othiym23 @dcposch @Flet @dcousens @jprichardson @xjamundx @watson @rstacruz @reggi @yoshuawuyts @bcomnes @jb55 |
|
Tested it on 4 or so (ES6 heavy) repos, all seems good 🎉 |
|
Thanks @yoshuawuyts! |
|
standard |
|
Just tried it on a very large project I'm working on, got this error: My config in "standard": {
"ignore": [
"static/"
],
"parser": "babel-eslint",
}If I remove |
|
@jprichardson Thanks for testing. This is an issue with the interaction between I think we'll just have to disable the |
There is an issue with the interaction between babel-eslint and eslint. See eslint/eslint#6274 I think we'll just have to disable the generator-star-spacing rule until ESLint has support for the async keyword. Bummer. See standard/standard#564 (comment)
|
standard @jprichardson Can you test it out now? |
|
Wow. Nice work @feross! |
|
@jprichardson Good to hear. Thanks for helping to test it out! |
|
Thanks for kicking this off! Any opposition to bumping to eslint-plugin-react@5.2.2? There have been quite a few fixes and additions since 5.0.1: Seems like a good time to update? |
|
Released |
|
Just merged one new rule: Require block comments to be balanced (#572) Released standard |
|
@feross 👍 👍 Tried out |
|
@timoxley 👍 👍 👍 great to hear! what do you think of the jsx change? |
@feross I do understand & accept the sentiment in standard/eslint-config-standard#27, though it probably wouldn't be my preference.
|
|
@feross I think you could head-off many complaints if standard promoted the use of Created an issue for this: #576 Update: Message promoting |
|
I agree with @timoxley that Maybe it could go into the error output? |
|
I fully agree with #564 (comment), in that I'm not sure the benefits out weigh the extra rule. |
|
So the JSX double quoting rule requires mixing of double/single quotes when doing any kind of inline JS in JSX: <div
doubleQuotes="just because this is static"
butForDynamicValues={singleQuotes === 'are' ? 'needed' : 'now'}
/>Or a more realistic example: <div title="Help Text" className={selected === item.id ? 'selected' : 'unselected'}>
{item.content}
</div>This converted me to a mild 👎 about this change; needing to use two quoting styles on the same line is not very "don't make me think" IMO. One rule > Two rules |
|
I'm not a fan of double quotes in jsx. One of the things that turned me on to standard was its simplicity. I think this is a step backward in that respect. |
|
@feross Another option could be for For reference, this is the current error when running the latest standard beta ( |
|
Standard 8 is gonna land soon. We gotta figure out the JSX double quotes situation... Given that all production versions of Standard before this don't allow JSX double quotes AND we don't have consensus, it should be removed from the Standard v8 release. Not too mention though other reasons like 1) Facebook themselves are inconsistent 2) it's confusing for new users (different rules (when/where) 3) JSX is not HTML. 4) |
You might disagree with the decision, but saying we have to "figure it out" ignores the multiple threads over which this has already been discussed. The fact that its in the release is it being "figured out". |
|
@tyrsius I think what @jprichardson is saying, is perhaps the final decision should be delayed rather than delaying |
|
@jprichardson the logical conclusion if there is no consensus isn't to enforce your taste but to remove the validation until there is a consensus. JSX is neither HTML nor JS so I'm not even sure it belongs in standard at all. In fact, your entire "JSX isn't HTML" argument is already violated by the enforcement of boolean properties being passed with the shorthand syntax (i.e. That said, there was a consensus. Just one you happen to disagree with. |
There's also some consensus that the current consensus is disagreeable. |
|
@timoxley which indicates this really shouldn't be part of standard to begin with. |
|
Agreed with @pluma. It should just be removed. I really enjoy using standard but I can't stand single quotes in my html, OCD about it, and whether you see it as html or not, JSX to me is html-like, so that OCD triggers there. I'd hate to have to deviate away from the ease of just using standard all because of this. |
|
I don't think it should be removed. Standard is all about just picking one way and sticking with it. I don't see any great advantage with either one, but having it not enforce any of them would be worse. My vote goes to @feross just picking one of them. It's not like it going to affect anyones day to day life. Both ways are easy to fix with the new |
Good idea. Let's skip running PR here: #590 |
Yeah, tell me about it. Either decision we make, there are going to be some folks who aren't happy. That's just the way a curated style guide like this works. There's no clear winner, IMO. Quoting some of the arguments from this thread, here's how I would sum this up: Pros for JSX double quotes:
Pros for JSX single quotes:
The But in attempting to switch some of my own code to the new v8 style, I'm running into situations where the intermixing of single and double quotes feels like it's actually reducing clarity. This is a typical example: <img className="poster" alt={this.getAltText('poster')} />In this situation, the rule is not reducing the likelihood of errors or increasing the clarity of the code. There's added cognitive overhead to remember when to use each type of quote. I worry that beginners won't be able to figure out when to use each type of quote, because we've taken a simple rule ("always use single quotes") and made it more complex ("use single quotes for JS, use double quotes for JSX"). There's no perfect decision here. But I think we should revert to standard v7 behavior ("always use single quotes") since that's the simpler choice. Note that allowing any type of quote isn't acceptable. Whenever there's two ways to do something without a clear winner, |
See rationale here: standard/standard#564 (comment)
|
Just published standard
And, changed rule:
I promoted this release to the "latest" npm dist-tag so it gets installed with If there are no issues, this release will become the official standard v8.0.0 release on September 1, 2016. |
|
I just realized that my trip to China on August 26 might interfere with the planned September 1 release date. So, new release date: August 23 (one week early). That way I have a couple days to fix any issues that might come up. Also, there are plenty of contributors who have github/npm permission who can step up if some urgent issue surfaces while I'm gone. |
|
|
|
@feross you probably should make a non-beta release of |
|
@Kovensky good call, done |
|
@feross Should |
|
@robinpokorny Done |
https://github.com/feross/standard/blob/master/CHANGELOG.md 8.4.0 - 2016-10-10 Update ESLint from 3.6.x to 3.7.x. 5 additional rules are now fixable with standard --fix! Use more conservative semver ranges #654 8.3.0 - 2016-09-29 The last release (8.2.0) added ES7 support. This release (8.3.0) adds ES8 support ...just 3 days later! This release should eliminate the need to specify babel-eslint as a custom parser, since standard can now parse ES8 (i.e. ES2017) syntax out of the box. That means async and await will just work. Support ES8 (i.e. ES2017) syntax. 8.2.0 - 2016-09-26 For many users, this release should eliminate the need to specify babel-eslint as a custom parser, since standard can now parse ES7 (i.e. ES2016) syntax out of the box. Support ES7 (i.e. ES2016) syntax. Update ESLint from 3.5.x to 3.6.x. 4 additional rules are now fixable with standard --fix! 8.1.0 - 2016-09-17 Update ESLint from 3.3.x to 3.5.x. Around 10 additional rules are now fixable with standard --fix! 8.0.0 - 2016-08-23 This release contains a bunch of goodies, including new rules that catch potential programmer errors (i.e. bugs) and enforce additional code consistency. However, the best feature is surely the new --fix command line flag to automatically fix problems. If you ever used standard-format and ran into issues with the lack of ES2015+ support, you'll be happy about --fix. standard --fix is built into standard v8.0.0 for maximum convenience, it supports ES2015, and it's lightweight (no additional dependencies since it's part of ESLint which powers standard). Lots of problems are already fixable, and more are getting added with each ESLint release. standard also outputs a message ("Run standard --fix to automatically fix some problems.") when it detects problems that can be fixed automatically so you can save time! With standard v8.0.0, we are also dropping support for Node.js versions prior to v4. Node.js 0.10 and 0.12 are in maintenance mode and will be unsupported at the end of 2016. Node.js 4 is the current LTS version. If you are using an older version of Node.js, we recommend upgrading to at least Node.js 4 as soon as possible. If you are unable to upgrade to Node.js 4 or higher, then we recommend continuing to use standard v7.x until you are ready to upgrade Node.js. Important: We will not be updating the standard v7.x versions going forward. All bug fixes and enhancements will land in standard v8.x. Full changelog below. Cheers! New features Upgrade to ESLint v3 (http://eslint.org/docs/user-guide/migrating-to-3.0.0) #565 BREAKING: Drop support for node < 4 (this was a decision made by the ESLint team) Expose ESLint's --fix command line flag #540 standard-engine/#107 Lightweight, no additional dependencies, fixes dozens of rules automatically New rules (Estimated % of affected standard users, based on test suite in parens) Enforce placing object properties on separate lines (object-property-newline) #524 (2%) Require block comments to be balanced (spaced-comment "balanced") #572 (2%) Disallow constant expressions in conditions (no-constant-condition) #563 (1%) Disallow renaming import, export, and destructured assignments to the same name (no-useless-rename) #537 (0%) Disallow spacing between rest and spread operators and their expressions (rest-spread-spacing) #567 (0%) Disallow the Unicode Byte Order Mark (BOM) (unicode-bom) #538 (0%) Disallow assignment to native objects/global variables (no-global-assign) #596 (0%) Disallow negating the left operand of relational operators (no-unsafe-negation) #595 (0%) Disallow template literal placeholder syntax in regular strings (no-template-curly-in-string) #594 (0%) Disallow tabs in file (no-tabs) #593 (0%) Changed rules Relax rule: Allow template literal strings (backtick strings) to avoid escaping #421 Relax rule: Do not enforce spacing around * in generator functions (standard/standard#564 (comment)) This is a temporary workaround for babel users who use async generator functions.
|
@feross You forgot to mention one Pros for JSX double quotes and it is the most important of all: JSX is treated as HTML in most editors, so they use double quotes by default. I mean when you start typing an attribute and then choose from autocomplete options. Editors insert double quotes in this case. And this behavior is even not configurable for some editors, eg. Intellij Idea. It is possible to disable auto-insertion of quotes at all, but not auto-insert single quotes: http://stackoverflow.com/questions/37635871/how-can-i-disable-syntax-autocomplete-of-jsx-properties. At this moment this is the only rule in Standard that forces me to overwrite rules. Kinda frustrating... |
Planned release date: September 1, 2016. (approx. 45 days from the date of this issue)
New features
--fixcommand line flag (Bring --format back #540) (add option/flag to invoke eslint's --fix feature standard-engine#107)New rules
(Estimated % of affected standard users, based on test suite in parens)
Changed rules
Enforce use of double quotes in JSX attributes (jsx-quotes) (1%, but likely more in private repos)BREAKING: This rule was changed to reflect the way the vast majority of developers quote HTML attributes (both in plain HTML and in the React community) (Change jsx-quotes to reflect usage in React? eslint-config-standard#27)babelusers who use async generator functions.Internal changes
The text was updated successfully, but these errors were encountered: