What is the difference between "user code" and "dependency code"?
How can we tell the difference between the two?

We can't use the import path and say "it has to have a ./ or a ../ for the import path" because tsconfig path mapping is a very commonly used thing.

You can't even really say "it's in node_modules" because yarn/pnpm monorepo workspaces are another very commonly used thing and those work via node_modules.

The key to considering this feature request is understanding how we can generically make this distinction.

What is the difference between "user code" and "dependency code"?
The key to considering this feature request is understanding how we can generically make this distinction.

My initial suggestion would have solely been: Everything in the purview of the current typescript project is user code. Whereas purview is defined as the files, include, exclude settings of the tsconfig applicable to the file being linted.

However, as you noted this falls flat for yarn/pnpm monorepos. So maybe it makes sense to additionally define a package name exclusion list (perhaps as a regex). If a package matches the list, it won't be considered as a source for deprecation annotations. This should be enough for monorepo use cases as their packages usually live under a common few prefixes.

My initial suggestion also needs some further thought wrt unit tests. They usually live in a different typescript project and usually don't refer to the code under test by its official package name.

The exclusion mechanism also needs to be based on information readily available to the linter, otherwise this'll likely result in an unacceptable performance hit. Given that I've no experience with this codebase, I can't make this judgement and would need some feedback with regards to my suggestions. Thanks for considering it!

Idea 💡 - what if we just create an allowlist like for no-floating-promises? This gives users control over what to consider internal (or whether to allow specific externally deprecated types if they so choose) rather than forcing us to infer it.

(more detailed docs for specifier format are on their way in #9587)

My initial suggestion also needs some further thought wrt unit tests. They usually live in a different typescript project and usually don't refer to the code under test by its official package name.

I think this can be at least partially addressed by specifying different configurations for the rule applying to different files (at the eslint config level, rather than within the rule), right?

The spec we designed was for ignoring specific types - we would need to extend it for values I believe.

Idea 💡 - what if we just create an allowlist like for no-floating-promises? This gives users control over what to consider internal (or whether to allow specific externally deprecated types if they so choose) rather than forcing us to infer it.

That does sound rather tedious, I'd prefer something less granular.

I think this can be at least partially addressed by specifying different configurations for the rule applying to different files (at the eslint config level, rather than within the rule), right?

I had the following case in mind: The tests have their own tsconfig.spec.json e.g. to allow different "module" settings as jest has (had?) trouble with ES modules. Thus they wouldn't be in the same tsconfig purview as the library code. Of course you could set no-deprecated to warn for the tests, but that is a comparatively blunt fix.

+1 from me on using the TypeOrValueSpecifier format as previously used in no-floating-promises and other rules. Blanket-ignoring all constructs in a particular folder is pretty heavyweight. I think we'd want to try out the same standard format as other rules before adding in something big like that.

Marking as evaluating community engagement to see if a lot of folks ask for this. Specifically, what's under consideration is adding an allow option using our standard TypeOrValueSpecifier format.

Strong +1. Enabled it for several projects and there are many reasons for disabling the rule on a per-API basis:

• Platform APIs that need graceful fallback for old envs
• Using our own API like the OP

This would be super useful to me right now in #10496. I want to deprecate our API externally, and gradually replace it internally.

I'm also +1 on this. So given that we have three team members in favor and an internal use case, marking as accepting PRs. 🚀