no-undefined doesn't allow undefined as an object property

[YodaDaCoda]

Tell us about your environment

• ESLint Version: v3.14.0
• Node Version: v6.9.4
• npm Version: 3.10.10

What parser (default, Babel-ESLint, etc.) are you using?
default

Please show your full configuration:

{
  "parserOptions": {
    "ecmaVersion": 6
  },
  "env": {
    "browser": true
  },
  "globals": {
    "jQuery": false
  },
  "rules": {
    "quote-props": ["error", "consistent-as-needed"],
    "no-undefined": "error"
  }
}

What did you do? Please include the actual source code causing the issue.

'use strict';

var foo = {
  undefined: 'bar',
};

What did you expect to happen?
undefined should be permitted as an unquoted object property.

What actually happened? Please include the actual, raw output from ESLint.
no-undefined produces an error. Quoting undefined (which would otherwise be a workaround) produces an error from quote-props.

Given that undefined is a permissable object property name, I believe no-undefined should be modified to permit this behaviour.

[platinumazure]

Reproduced in the online demo.

I assume all of the following should be valid cases.

'use strict';

var foo = {
  undefined: 'bar',
};

// ES6 destructuring, case 1
var { undefined: bar } = foo;

// Invalid? ES6 destructuring, case 2
var { bar: undefined } = foo;

[ljharb]

They might only be valid in strict mode, with an ecmaVersion > 5 or 6 - but I think there's other rules that can handle that.

var { undefined: bar } = foo; should be valid because it's extracting a property named "undefined" and putting it into a variable named "bar" - but I don't think var { bar: undefined } = foo; should be valid since it's creating a variable named "undefined" from foo.bar.

[platinumazure]

@ljharb What about in sloppy ES6, can you assign to undefined via assignment pattern then?

[not-an-aardvark]

undefined is a non-writable property of the global object in ES5 and above, so it can't be globally reassigned in any context (sloppy or strict). The only difference with strict mode is that a runtime error will occur rather than a silent failure.

A local variable called undefined can be created in any context, regardless of sloppy/strict mode.

[platinumazure]

@not-an-aardvark Thanks, that helps a bit. Unfortunately I'm not super familiar with destructuring. Do these cases create/shadow undefined in local scope, or try to write to the undefined in global scope?

// Case 1
var { bar: undefined } = foo;

// Case 2
({ bar: undefined } = foo);

Feel free to edit this post with inline remarks if it's easier. Thanks for your help.

[not-an-aardvark]

Case 1 creates a local variable undefined which shadows the global variable. Case 2 reassigns the global variable.

The ES5 equivalents of those cases are:

// Case 1
var undefined = foo.bar;

// Case 2
undefined = foo.bar;

[platinumazure]

Okay. I assume that assigning to undefined should probably be invalid in each case, then, since it's still trying to use undefined as an identifier rather than it coming up as an object key. I'll write a PR with that assumption, let me know either here or in the PR if that's wrong.