Validate object literals

Please describe what the rule should do:

I propose to add a new object literal validation. In case the properties on an object are not dynamically manipulated in any way and the object is also not exported it would be possible to validate all accesses to properties of that object. That way it would be possible to check if the static property accesses are all valid. Besides that it would also be possible to validate for unused properties in case property access is only static and the object is never exported. [Update]: There are a couple further things that would have to be though about like referencing the same object with a different variable name and then accessing the properties / setting them and passing the object to a function or using destructuring. The rule could therefore not warn about a lot of things but I believe this could a) be maybe improved later on and b) would still provide benefit for all possible cases. [/Update]

What category of rule is this? (place an “X” next to just one item)

[ ] Enforces code style [x] Warns about a potential error [ ] Suggests an alternate way of doing something [ ] Other (please specify:)

Provide code examples that this rule will warn about:

const kConstants = {
  a: true,
  b: false,
  errorOnNotAccessed: 'yes please' // Should error
}
Object.defineProperty(kConstants, 'c', {
  value: 'works'
}

// ... application code ...
function doThings(bar) {
  const randomAccess = kConstants[bar]
  const abc = kConstants.c
  const accessError = kConstants.d // Should error
  // ...
}

// Object is not exported
module.exports = { doThings }

Why should this rule be included in ESLint (instead of a plugin)?

It could provide early feedback when users access non existing properties on an object.

[not-an-aardvark]

Personally, I think it would be better to use a dedicated type checker such as TypeScript for this, because it would be able to do a much better job than ESLint and catch many more errors. Only being able to catch errors in a very small subset of cases (when there is no aliasing, and the object isn’t passed to any functions that could modify it, and the object is never passed outside of the file) makes me think that this rule wouldn’t be very useful.

[eslint-deprecated[bot]]

Unfortunately, it looks like there wasn’t enough interest from the team or community to implement this change. While we wish we’d be able to accommodate everyone’s requests, we do need to prioritize. We’ve found that issues failing to reach accepted status after 21 days tend to never be accepted, and as such, we close those issues. This doesn’t mean the idea isn’t interesting or useful, just that it’s not something the team can commit to.

Thanks for contributing to ESLint and we appreciate your understanding.