This was a good initiative but has turned to become too restrictive

[gsklee]

Our project went from 0 to 900+ errors overnight because somehow the updated rules or linter decided to suddenly begin issuing warnings against whitespaces around JSX attribute equal signs. I was a big pusher for the standard within my organization, but with an ever-changing ruleset like this, I honestly am no longer sure how can I continue to sell or advocate for your initiative.

[feross]

@gsklee Can you share a code example that used to pass but is now failing?

We lock the ESLint configuration version to exact versions so that standard won't change out from under you.

But we have a looser ESLint version range (~2.10.2) and really loose ranges for the ESLint plugins we use (using the ^ semver operator).

If you share what broke for you, we can issue a patch update that locks the faulty dependency.

[rstacruz]

I've experienced this before. It's foo={ a } that's not allowed anymore,
and foo = {a}

On Mon, May 30, 2016, 12:55 PM Feross Aboukhadijeh notifications@github.com
wrote:

@gsklee https://github.com/gsklee Can you share a code example that
used to pass but is now failing?

We lock the ESLint configuration version to exact versions
https://github.com/feross/standard/blob/master/package.json#L16-L17 so
that standard won't change out from under you.

But we have a looser ESLint version range
https://github.com/feross/standard/blob/master/package.json#L15 (~2.10.2)
and really loose
https://github.com/feross/standard/blob/master/package.json#L18-L20
ranges for the ESLint plugins we use (using the ^ semver operator).

If you share what broke for you, we can issue a patch update that locks
the faulty dependency.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#533 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAEika-fgVMdZDGgNvUT4XbB7gK0xOmCks5qGm3LgaJpZM4IpeqO
.

[gsklee]

Exactly what @rstacruz has mentioned.

[feross]

@gsklee I just did a little investigating and this was actually part of standard v6 which was released on February 5, 2016. We're currently on standard v7 and 4 months later. You're the first person to open an issue about this, so it doesn't seem to have affected many users.

In general, we don't add new rules that disrupt lots of users, even in a new major version. We have a test suite that lets us assess the impact of a change on the ecosystem of users and this didn't affect any of the repos we test on.

One of the tenets of standard is to eliminate ambiguity whenever possible. So, if there's one way of writing some code, and there's an eslint rule to enforce that one way, we'll enable it. This is service of our goal: eliminating style discussions on your team.

Sorry that you're experiencing new errors after upgrading. I recommend downgrading to standard v5.x and only upgrading if/when you're ready to change your code. In the future, you can participate in discussions before a release if you're interested.

Cheers!