Release proposal: standard v7

[feross]

Placeholder to track things for the release of standard v7, in the near future.

Changes

• Remove "rules" configuration option (#367) from package.json (Reasoning is here)

New rules

Estimated % of affected standard users, based on test suite

• Require camelCase (camelcase) [4%]
• Disallow unnecessary escape usage (no-useless-escape) [4% -- but, including many bugs]
• Disallow duplicate imports (no-duplicate-imports) [0%]
• Disallow unmodified conditions of loops (no-unmodified-loop-condition) [0%]
  • Blocked on: eslint/eslint#5166
• Disallow whitespace before properties (no-whitespace-before-property) [0%]
  • Blocked on: eslint/eslint#5167
• Validate spacing before closing bracket in JSX (react/jsx-space-before-closing) [0%]
• Disallow control flow statements in finally blocks (no-unsafe-finally) [0%]
• Disallow unnecessary computed property keys on objects (no-useless-computed-key) [0%]

Removed rules

• Require parens in arrow function arguments (arrow-parens)

[yoshuawuyts]

Hmh, interesting - should we remove plugins entirely or keep them around? With the removal of the React rules (in v6) + no way of plugins people using React would have to switch to standard-react or something similar, right?

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

[feross]

React style rules were removed, but JSX parsing and even some JSX formatting rules remain in standard v6. :)

[yoshuawuyts]

Cool ✨

[yoshuawuyts]

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

[kaicataldo]

Hey there! Just wanted to let you know I'm working on the no-whitespace-before-property bug and have a PR open for it.

[feross]

@kaicataldo That's super helpful! Thanks!!

[maxogden]

I agree with everything in #399 (comment) for the record.

Regarding plugins, I've never used them but do we expect people to use custom plugins to override standard behavior (e.g. like this #399 (comment))? Or is it just for extending standard? I'm cool with extending, but not overriding. If it's impossible to enforce one and not the other, then I'd probably remove it (e.g. err on the side of less features that can confuse users in the long term)

[feross]

The plugins option can't be used to actually set any rules as of eslint v2.0.0. See this note in the 2.0.0 changelog. If we don't expose rules, then plugins can only transform the AST before the linting happens.

[dcousens]

ACK on all of the above. No configuration is why I use standard.

[dcousens]

IMHO @feross if 6.0.0 was the only 'configurable' version of standard, then I'd be happy with leaving it as is, bumping to 7.0.0 with all of standard-strict enabled.

[LinusU]

@feross Why remove no-regex-spaces? I couldn't find any reasoning or an issue on it...

[timoxley]

we probably want to make sure everyone is on board with this release hah

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.

[jprichardson]

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 😛

[maxogden]

all hail benevolent lord feross! ⚔🛡🏆🍻👑

On Wednesday, February 17, 2016, JP Richardson notifications@github.com
wrote:

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.

[image: 👍] 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 https://github.com/feross could then make
the final call :)

—
Reply to this email directly or view it on GitHub
#404 (comment).

Sent from my phone

[dcousens]

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.

[feross]

The release candidate suggestion is a good one. I've done that in the past:

$ npm show standard versions

[ '1.0.0',
  '1.0.1',
  ...
  '3.0.0-alpha',
  '3.0.0-beta',
  '3.0.0-beta2',
  '3.0.0-beta3',
  '3.0.0-beta4',
  ...
  '5.0.0-0',
  '5.0.0-2',
  '5.0.0-3',
  '5.0.0-4',
  '5.0.0-5',
  '5.0.0-6',
  '5.0.0-7',
  '5.0.0-8',
   ...

Will do that for v7.

[sotojuan]

I'd love a fix for #416!

[simonratner]

Comment regarding promise/catch-or-return -- does it allow for yield as well as return?
Yielding promises is common when using something like tj/co.

[xjamundx]

@simonratner It doesn't yet, but might be easy to add. Can you add an issue over there:
https://github.com/xjamundx/eslint-plugin-promise/issues

[simonratner]

Accept yield in catch-or-return: xjamundx/eslint-plugin-promise#9

[feross]

Going to punt on catch-or-return for v7.0.0 because it is causing a lot of packages to fail, even with allowThen enabled. We can discuss it for later.

[feross]

Hey everyone!

standard version 7.0.0-beta.0 was just released with the following changes. Please install it and give it a try! If everything looks good, this will become standard v7!

npm install -g standard@7.0.0-beta.0

Changes

• Remove "rules" configuration option (#367) from package.json (Reasoning is here)

New rules

Estimated % of affected standard users, based on test suite

• Require camelCase (camelcase) [4%]
• Disallow unnecessary escape usage (no-useless-escape) [4% -- but, including many bugs]
• Disallow duplicate imports (no-duplicate-imports) [0%]
• Disallow unmodified conditions of loops (no-unmodified-loop-condition) [0%]
  • Blocked on: eslint/eslint#5166
• Disallow whitespace before properties (no-whitespace-before-property) [0%]
  • Blocked on: eslint/eslint#5167
• Validate spacing before closing bracket in JSX (react/jsx-space-before-closing) [0%]

Removed rules

• Require parens in arrow function arguments (arrow-parens)

[sotojuan]

With this AVA test:

test('async', async t => {
  let x = await fn()

  t.is(x, 'hi')
})

I get: Parsing error: Unexpected token t. I'm guessing async/await is not supported yet?

[feross]

@sotojuan This is expected. It didn't work with the previous version of standard either. See https://github.com/feross/standard#can-i-use-a-custom-js-parser-for-bleeding-edge-es6-or-es7-support

[feross]

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.

[yormi]

When forgetting a space after the function keyword it says:

32:54  error  Missing space after *

I think it was clearer before !?

Moreover, npm is telling me the package is invalid. I'm not sur if that can be usefull info for you guys:

└── standard@7.0.0-beta.0  invalid

[sotojuan]

@feross Got it, thanks!

[feross]

@yormi It only shows "Missing space after *." when you're using a function *, right? With a normal function, the error message remains the same "Missing space before function parentheses."

The "invalid" message you're getting just means that you have a different version of standard in your package.json than the one that is currently installed. It's not an issue since you just installed v7 to test it out. You can make it go away if you update your package.json with:

npm install standard@beta --save-dev

[yormi]

It was with an async function (). I guess it's kind of the same semantic but since the written code is different, it might be nice to have a specific message, or if it's complicated to achieve, a mention somewhere in the README.

[feross]

@yormi This sounds to me like it's caused by babel-eslint which I assume you're using.

[feross]

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
http://eslint.org/docs/rules/no-useless-computed-key

Then I will release standard v7.

[feross]

Alright, standard v7 is released!

https://github.com/feross/standard/blob/master/CHANGELOG.md#700---2016-05-02
https://twitter.com/feross/status/727140207254970368