Suggestion: remove need to "only" quote properties that are invalid identifiers

[ianstormtaylor]

Right now the style guide recommends:

3.8 Only quote properties that are invalid identifiers.

Why? In general we consider it subjectively easier to read. It improves syntax highlighting, and is also more easily optimized by many JS engines.

// bad
const bad = {
  'foo': 3,
  'bar': 4,
  'data-blah': 5,
};

// good
const good = {
  foo: 3,
  bar: 4,
  'data-blah': 5,
};

But this is too strict for common sense situations where it's nicer to leave all properties quoted. For example, if you are dealing with an object whose properties always abide by slug-casing, then it's less confusing to actually quote all of them, instead of alternating between quoted any unquoted.

A live example of this actually already exists in this very repository 😄 when defining the ESLint rules in Javascript: https://github.com/airbnb/javascript/blob/master/packages/eslint-config-airbnb-base/rules/best-practices.js#L14

...

    // treat var statements as if they were block scoped
    'block-scoped-var': 2,

    // specify the maximum cyclomatic complexity allowed in a program
    'complexity': [0, 11],

    // require return statements to either always or never specify values
    'consistent-return': 2,

...

Going by the current style guide, complexity should not be quoted, but that would actually make the file more less symmetrical and thus a bit more tedious to maintain.

Instead, I think it should mention that maintaining a consistent quoting scheme is recommended when the casing of the properties is clearly defined, and doesn't lend itself to being unquoted.

[ljharb]

The rule files are meant to closely mimic JSON format, which is why the quoting rule isn't consistently applied there.

While you're always free to fork the guide, and/or override the rules to suit your needs, "less confusing" and "nicer" are subjective viewpoints that we don't agree with - personally I find it much nicer to only ever quote invalid identifiers, even in objects where they are mixed.

The eslint rule override to get the behavior you want is "quote-props": [2, "consistent-as-needed"].

[ianstormtaylor]

Wait...

I know the rule files are meant to mimc JSON. In fact that's exactly what I'm saying, it's a completely valid use case! And if someone had a similar thing inside of their repositories, it would also be a valid use case. Or if someone decided to do the same quoting style inside of a less-JSON-y Javascript file, because their target format only accepts dashed properties, it would be equally valid for them to decide to quote all the properties, since it's the same use case.

What I'm trying to argue is that the existing behavior is needlessly restrictive for what could be very valid use cases. The explanation for the restrictive current behavior is backed up by:

... In general we consider it subjectively easier to read. ...

It seems odd that such a valid use case, so common that it shows up inside this very repository, with seemingly no "do not lint" comments or otherwise, would not be accounted for...

[ljharb]

It's a use case, certainly. Whether it's valid or not is a separate matter.

A style guide should be aspirational. Sometimes you can follow it 100% - sometimes you need to deviate. The reality that deviations occur doesn't change the style guide - it just means your code has to apologize for the deviation with linter rule overrides.

However, you raise a valid point. I'll fix the violations in this repository so that we don't have those nasty quotes all over the place, and at least we won't be setting a bad example.