No warnings about setting a deprecated property
maranomynet opened this issue · comments
type T = {
new?: string;
/** @deprecated */
old?: string;
};
const myT: T = {
// I'd expcect an ESLint warning here, but there is none
old: 'value'
};
console.info(myT.old); // I only get a warning hereHow it looks in VSCode:
In fact VSCode doesn't warn (with a strike-through) about this either.
This may actually be related to an issue with TypeScript itself. It would possibly be enough to wait for a bug fix and then make sure the latest version of TypeScript is used with this plugin. Fingers crossed.
We just released an updated with latest deps in v1.3.0 maybe you can try it out and see if this is still an issue?
I seem to be having the same issue in v1.3.2 using TypeScript v4.5.4.
The plugin correctly picks up deprecated methods, but nothing seems to be reported for deprecated object properties.
Actually now that I look at this - it makes total sense as the plugin is only reporting usages of deprecated code.
And in your case declaring an object with deprecated property is not usage it's declaration so it's not reported.
Ah, okay. I was under the impression that the plugin would pick up everything annotated with @deprecated, be it methods or properties.
I do still think it would be beneficial to have this functionality for quickly and easily being made aware of usage of deprecated properties in our codebases. Is this functionality you'd consider in scope for this plugin?
Yeah, that distinction does not make any sense to me.
When I declare an object of a certain type, I'm effectively using it's interface-/type-declaration.
For example: When I pass a deprecated prop to a React component, I'm in-place declaring the props object and get no warning that I'm using (in way of passing) a prop that the component's author explicitly flagged as @deprecated.
The way things are now, the only person to ever see a warning of a deprecated prop/option is the library author who flagged the prop themself, but is forced to use those props to maintain back-compatibility.
Hmm this might actually be a valid use-case.
I will reopen the issue to track it and PRs are welcome 😊
This plugin does not detect deprecated properties when the definition is in another file.
I am wondering if there is any progress on this issue? We are trying to use this plugin in a large React project to deprecate props for certain components. Depending on the complexity, we may be interested in submitting a PR, but we would need some guidance
I don't think there was any meaningful progress to fix this bug, so you are more then welcome to try and figure a fix for it in a PR.
Unfortunately I could not be of help as I was not digging into eslint plugins (yet), maybe somebody else here can help but tbh I have no clue.
One thing I can suggest as a helping tool is to use some TS AST explorer which could give you an idea how the fix could be implemented.
NOTE: I just had a quick look into the ast explorer and noticed that TS 4.8 also now tracks deprecated symbols in it's flags but it does not mark deprecated property declarations as deprecated as well.
Type definition has deprecated flag (on PropertySignature symbol):
And property declaration (nor it's identifier) does not (as they have their own PropertyAssignment symbol):
And then property access is marked with deprecated flag (via PropertySignature symbol):
So seems like TS does not link PropertyAssignment with PropertySignature symbols which basically looses deprecated flag on declared props.
Would this be possible for react components by now? Since it seems TS knows this is deprecated, but eslint doesn't warn me:
