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 v7 #404
Comments
Hmh, interesting - should we remove plugins entirely or keep them around? With the removal of the React rules (in The purist in me doesn't mind at all: it won't affect me in the slightest. On the other hand: there's a good amount of people using React. Hmm |
React style rules were removed, but JSX parsing and even some JSX formatting rules remain in |
Cool ✨ |
ping @maxogden @mafintosh @othiym23 @dcposch @Flet @dcousens @jprichardson @xjamundx @watson @rstacruz @reggi @yoshuawuyts @bcomnes @jb55 - we probably want to make sure everyone is on board with this release hah |
Hey there! Just wanted to let you know I'm working on the |
@kaicataldo That's super helpful! Thanks!! |
I agree with everything in #399 (comment) for the record. Regarding |
The |
ACK on all of the above. No configuration is why I use standard. |
IMHO @feross if |
@feross Why remove |
For v7 & future major releases I'd like to suggest a policy of at least a few weeks of release candidate time to collect feedback based on running the latest versions against real codebases. |
👍 Agreed. I think this is important because part of the job of standard is to help us have practical, common-sense (forgive the politico speech, haha) defaults when writing code. This would allow most of us to test it out and be sure that these rules make sense. And if there's disagreement, Lord @feross could then make the final call 😛 |
all hail benevolent lord feross! ⚔🛡🏆🍻👑 On Wednesday, February 17, 2016, JP Richardson notifications@github.com
Sent from my phone |
Was a milestone set for the release date? It seemed like the release culminated a lot of merging over the course of 2-3 days and then it was released without further feedback? :) Not fussed, all hail, but, might have saved us the fat arrow parentheses screw up. |
The release candidate suggestion is a good one. I've done that in the past:
Will do that for v7. |
I'd love a fix for #416! |
Comment regarding promise/catch-or-return -- does it allow for |
@simonratner It doesn't yet, but might be easy to add. Can you add an issue over there: |
Accept yield in catch-or-return: eslint-community/eslint-plugin-promise#9 |
Going to punt on |
Hey everyone!
Changes
New rulesEstimated % of affected standard users, based on test suite
Removed rules
|
With this AVA test: test('async', async t => {
let x = await fn()
t.is(x, 'hi')
}) I get: |
@sotojuan This is expected. It didn't work with the previous version of |
Happy to see there are no complaints about v7 yet. Let's release the current version as v7 in 48 hours from now. So April 30. |
When forgetting a space after the function keyword it says:
I think it was clearer before !? Moreover, npm is telling me the package is
|
@feross Got it, thanks! |
@yormi It only shows "Missing space after *." when you're using a The "invalid" message you're getting just means that you have a different version of
|
It was with an |
@yormi This sounds to me like it's caused by |
Alrighty, I'm going to upgrade eslint to 2.9.0 and add two new uncontroversial rules that were added in 2.9.0. http://eslint.org/docs/rules/no-unsafe-finally Then I will release standard v7. |
Alright, standard v7 is released! https://github.com/feross/standard/blob/master/CHANGELOG.md#700---2016-05-02 |
Placeholder to track things for the release of standard v7, in the near future.
Changes
package.json
(Reasoning is here)New rules
Estimated % of affected standard users, based on test suite
Blocked on:no-unmodified-loop-condition
false positive eslint/eslint#5166Blocked on:no-whitespace-before-property
false positive eslint/eslint#5167finally
blocks (no-unsafe-finally) [0%]Removed rules
The text was updated successfully, but these errors were encountered: