no-reserved-keys and quote-props have incompatibilities.

[terinjokes]

The following Identifiers give warnings from no-reserved-keys when not quoted, but also give warnings from quote-props when set in "asNeeded" mode.

abstract
boolean
byte
char
double
final
float
goto
implements
int
interface
long
native
package
private
protected
public
short
static
synchronized
throws
transient
volatile

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[nzakas]

Can you include some actual examples and the output you're seeing?

[terinjokes]

var minimist = require('minimist');
var args = minimist(process.argv.slice(2), {
  string: 'env',
  boolean: ['sourcemaps', 'minify'],
  'default': {
    env: 'development'
  }
});

If "boolean" is unqouted:

2:43 error  Reserved word 'boolean' used as key  no-reserved-keys

If "boolean" is quoted:

4:2  warning  Unnecessarily quoted property `{{name}}` found  quote-props

[nkbt]

Using CSS 'as JS' causes this problem.

const imgStyle = {
  'float': 'right'
};

// error  Unnecessarily quoted property `float` found  quote-props

const imgStyle = {
  float: 'right'
};

// error  Reserved word 'float' used as key  no-reserved-keys

[jrvidal]

Would it make sense to merge the two rules? We could keep quote-props with an additional option such as "as-needed-es3".

[nzakas]

We'd need to work on the option name, but it would seem helpful to standardize on just quote-props

[jrvidal]

OK, I'll work on a PR.

[nzakas]

Can you discuss what you're planning on doing first? Make it easier for people to chime in (and less thrash on the PR)

[jrvidal]

Hum, I was planning to merge the two rules into quote-props, I'm not sure if that what you're asking. That means:

• Mark no-reserved-keys as deprecated.
• Import its keyword list to quote-props and use it for as-needed-es3 (working name).

[nzakas]

We've had some issues with keyword lists. See: #1616

I'm not sure if as-needed-es3 is clear enough or if there needs to be something more (or ability to specify which words to enforce).

[jrvidal]

As far as I can see, the only rules that deal with explicit keyword lists are no-reserved-keys (quote-props after the merge) and dot-notation. I think we could refactor them to use a common keyword list, broken down in ES3/ES5 categories. We could tackle #1616 later by refining that list. Does it make sense?

BTW, I couldn't find any examples of a common resource used by several rules, apart from the context API. In other words, would this approach make sense?

/**
 * Rule X
 */

var keywords = require("../utils/keywords");

// ...

// cc @nzakas

[nzakas]

We've debated how to share amongst rules, and I think at some point we just need to go for it and see what happens, so that approach is fine by me.

I think what we really need for this rule is a configuration like:

quote-props: [2, "as-needed", { keywords: true }

[jrvidal]

A few odds and ends I found:

• Numbers as properties:

  // (1a) with "as-needed"
  var x = ({100: 1});
  
  // (1b) with "as-needed"
  var x = ({1e2: 1});
  
  // (1c) with "as-needed"
  var x = ({'100': 1});
  
  // (1d) with "as-needed"
  var x = ({'1e2': 1});

  With as-needed, (1c) throws, all the others pass. I think the user should be able to configure this behavior as well. I'm thinking of an additional numbers option:

  • numbers: "always": (1c) and (1d) pass
  • numbers: "ambigous": (1a) and (1d) pass
  • numbers: "never": (1a) and (1b) pass

• Special properties:
  Right now the rule interacts in funny ways with all "special properties":

  // (2a) with "always" and ecmaFeatures
  var x = {[foo]: 1};
  
  // (2b) with "always" and ecmaFeatures
  var x = {foo,};
  
  // (2c) with "as-needed"
  var x = {get "foo"() {}}
  
  // (2d) with "as-needed" and ecmaFeatures
  var x = {"foo"() {}}
  
  // (2e) with "as-needed" and ecmaFeatures
  var x = {["foo"]: 1}

  All these throw. I propose to ignore all "special" properties for now. We can discuss later whether to include them in this rule or to create a new one.

[nzakas]

@jrvidal please open a separate issue for those and include the actual ESLintb output. This topic is too tangential for this issue.