Easy way for libraries to define deprecated methods and have them linted. about eslint-plugin-unicorn HOT 9 CLOSED

Closing for 4 years of inactivity and because this exists:

• JavaScript: https://github.com/benmosher/eslint-plugin-import/blob/master/docs/rules/no-deprecated.md
• TypeScript: https://github.com/gund/eslint-plugin-deprecation

Reopen if unicorn needs to have its own version.

from eslint-plugin-unicorn.

Interesting! Can you show an example of how it would look?

from eslint-plugin-unicorn.

Relevant:

• https://github.com/benmosher/eslint-plugin-import/blob/master/docs/rules/no-deprecated.md
• import-js/eslint-plugin-import#193
• import-js/eslint-plugin-import#302

from eslint-plugin-unicorn.

Oh wow. That's a cool way to do it.
Might be slow though. Doesn't it have to load and parse every dependency?

from eslint-plugin-unicorn.

@benmosher ⬆️

from eslint-plugin-unicorn.

It does parse every dependency, but if you're already using the other rules that do static analysis the plugin only parses each dependency at most once, so turning on the no-deprecated rule doesn't add much extra time.

I also wrote an ESLint memoizing parser as an experiment, to cut parse time in half by allowing ESLint proper and the import plugin to share the same parsed AST instead of each parsing their own. It helps, but doesn't even really matter until the project gets big.

My day job application is made of about 1500 module files, IIRC, and takes ~15s to fully lint with the memo-parser.

from eslint-plugin-unicorn.

BTW, it currently uses JSDoc but could use whatever. It's not obvious to me how prevalent JSDoc is, I mostly use it internally to flag myself and others with yellow rectangles around deprecated identifiers in Sublime.

from eslint-plugin-unicorn.

@benmosher I assume the ESLint caching works fine with eslint-plugin-import?

from eslint-plugin-unicorn.

Yes and no. If you change an imported file, the files that import it won't be invalidated so if any import issues have been introduced, they won't show up. I.E.:

Module A imports B. Lint A with --cache, then delete B, then re-lint A with --cache. I would expect it not to report B as missing since A's content still matches the last lint execution. I am not super-familiar with ESLint's caching though, so I may be wrong.

This is why I use eslint_d for faster console and Sublime linting; the in-process caches of exports default to invalidating after 30s, so an eslint_d re-lint of A would eventually report B as unresolved.

from eslint-plugin-unicorn.