✅ Deploy Preview for docs-eslint ready!

Name	Link
🔨 Latest commit	a8cc786
🔍 Latest deploy log	https://app.netlify.com/projects/docs-eslint/deploys/6836062a772f1e0008f54704
😎 Deploy Preview	https://deploy-preview-19772--docs-eslint.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

How should this new option work in case of nested properties? For example, the current behavior is as follows:

/* eslint no-restricted-properties: [2, {
    "object": "config",
    "allowProperties": ["settings", "version"]
}] */

config.apiKey.settings = "12345"; // Error: 'config.apiKey' is restricted from being used
config.timeout = 5000; // Error: 'config.timeout' is restricted from being used 

config.version.node = "1.0.0"; // No error
config.node.version = "1.0.0"; // Error: 'config.node' is restricted from being used

Now, let's suppose I want to allow only config.apiKey.settings & not config.settings, how should my config look?

IMHO, the rule should apply to the immediate property and therefore any of its sub-properties.

Allow config.settings and any sub-properties

"object": "config",
"allowProperties": ["settings", "version"]

For controlling nested properties, the rule can consider the following format:

"object": "config.node",
"allowProperties": ["version"]

It should be allowed to enter multiple rules e.g.

no-restricted-properties: [2, 
  {
    "object": "config",
    "allowProperties": ["settings", "version"]
  },
  {
    "object": "foo",
    "allowProperties": ["bar", "barbell"]
  },
  {
    "object": "config.node",
    "allowProperties": ["number", "value"]
  },
]

I agree. The rule should look only at immediate properties and not look at any other level. This mirrors the existing behavior of the rule.

Makes sense. Let's make the behavior as per #19772 (comment)

/* eslint no-restricted-properties: [2, {
    "object": "config.node",
    "allowProperties": ["version"]
}] */

config.node.version = "1.0.0"; // No error
config.node.other = "1" // Error

I think supporting nested properties/complex objects is out of scope for this change, as that feature is not currently supported by this rule, and the accepted proposal is just to add "allowProperties" as the inverse of "property".

I agree with @mdjermanovic that supporting nested properties is out of scope for this change. I've opened a separate issue to discuss this.