Allow the `object` or `property` option to be omitted with `no-restricted-properties`

What rule do you want to change?

no-restricted-properties

Does this change cause the rule to produce more or fewer warnings?

The default behavior of the rule would be unchanged.

How will the change be implemented? (New option, new default behavior, etc.)? What will the rule do after it’s changed?

Currently, no-restricted-properties accepts a list of objects with the object and property keys. Both options are required.

It would be useful to be able to disallow access to a property on every object, rather than having to provide explicit object names. For example, one might want to disallow use of the deprecated __defineGetter__ property, which is currently not possible with ESLint.

Similarly, it would be useful to be able to disallow all property access for a particular object, without specifying property names. For example, one might want to encourage use of the require() function, and disallow access to require.resolve(), require.cache, etc.

I propose that we make the object and property arguments optional. If property is provided and object is omitted, an error is reported whenever property is accessed from any object. If object is provided and property is omitted, an error is reported whenever any property of object is accessed.

If both object and property are omitted, ESLint should raise an error about an invalid schema. (The consistent behavior would be to disallow all forms of property access, but it’s unlikely that anyone would actually want to do this and so it would cause confusion.)

Please provide some example code that this change will affect:

/* eslint no-restricted-properties: [2, {"property": "__defineGetter__"}] */

foo.__defineGetter__(bar, baz); // report error
bar.__defineGetter__(bar, baz); // report error

/* eslint no-restricted-properties: [2, {"object": "require"}] */

require('foo') // ok
require.resolve('foo') // report error
require.cache // report error
require['foo'] // report error

What does the rule currently do for this code?

It causes ESLint to throw an error because the schema is considered invalid.

[platinumazure]

Ah, I didn’t realize JSON Schema would let us require just one or the other (in conjunction with anyOf). Okay, I like the original proposal (just omit the config properties as needed) better and withdraw my suggestion of null valuing.

[ljharb]

@alecharmon and also all-properties? The current proposal seems the clearest to me.