JSDoc @deprecated diagnostics

[kitsonk]

deno_lint should be able to parse the JSDoc for symbols and identify ones that have the @deprecated flag and issue a diagnostic if the @deprecated APIs are being used.

[lucacasonato]

This is not possible without type information.

[kitsonk]

How so? swc bundling tracks symbols across modules without type information, so the swc parser is aware of what symbols are used where and what JSDoc is associated with them.

[lucacasonato]

The linter operates on single files though, not on an entire graph. We don't have info about any symbols outside of the file being linted.

[kitsonk]

At the moment, and that is different than requiring type information.

[petamoriken]

FYI: denoland/deno#7982 (comment)

Annex B will be annotated as @deprecated in TypeScript 4.5 and later, it will may be possible to prevent it from being used.
microsoft/TypeScript#43709

[iuioiua]

This would be an amazing addition to the linter. Is this now possible?

[iugo]

The import/no-deprecated rule mentioned in https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/no-deprecated.md is very useful. However, it does bring additional complexity as it's difficult to effectively determine deprecation within a single file. Nevertheless, this functionality is important - if we could associate one layer of external dependencies with a single file, we could perform checks similar to import/no-deprecated. While this would inevitably increase checking time, it should be worth the trade-off.

[petamoriken]

Perhaps it would be better to support this with deno check.