Build better import paths for declaration emit/typeToString from reexports if possible

[Wesley Wigham (weswigham)]

Also, issue an error on relative/deep node_modules import generation (under moduleResolution: "node") if a better specifier cannot be found (which can happen if your type definitions need to depend on the types of a dependency of a dependency which you do not yet directly depend on). While such paths technically work on the compiling system, the resulting .d.ts file will be non-portable; this can cause issues for package consumers, so it is best to mark it as needing a type annotation to fix the problem.

Fixes#26985

[Wesley Wigham (weswigham)]

TypeScript Bot (@typescript-bot) test this

[TypeScript Bot (typescript-bot)]

Heya Wesley Wigham (@weswigham), I've started to run the extended test suite on this PR at 4f50766. You can monitor the build here. It should now contribute to this PR's status checks.

[Wesley Wigham (weswigham)]

Andy (Andrewkraft) (@Andy-MS) you wanna look over this?

[Wesley Wigham (weswigham)]

Ron Buckton (@rbuckton) done.

[Daniel Rosenwasser (DanielRosenwasser)]

is {1} the name of the package? Or the module itself?

[Daniel Rosenwasser (DanielRosenwasser)]

What about

Generating a declaration for '{0}' requires generating a reference to the module '{1}'; however, this is susceptible to breaking upon distribution. Provide an explicit annotation or add an explicit dependency on '{2}'.

[Wesley Wigham (weswigham)]

From the new test:

The inferred type of 'x' requires a reference to a module at 'foo/node_modules/nested' to name, which would likely break on type redistribution. A type annotation is necessary.

It's the specifier we would generate were we to emit it.

[Wesley Wigham (weswigham)]

We have an accessibility error

"The inferred type of '{0}' references an inaccessible '{1}' type. A type annotation is necessary."

which this message is templated after. I imagine we should use consistent language.

[Ron Buckton (rbuckton)]

Barring Daniel's feedback and a minor nitpick, this seems fine.

[Ron Buckton (rbuckton)]

This nesting is unnecessarily complicated. What about this:

letresults=links.extendedContainersByFile&&links.extendedContainersByFile.get(id);if(results)returnresults;

[Daniel Rosenwasser (DanielRosenwasser)]

Naming the type of '{0}' requires a reference to a module at '{1}' to name, which would likely break on type redistribution. A type annotation is necessary.

or

``
Generating a declaration for the type of '{0}' requires a reference to a module at '{1}' to name, which would likely break on type redistribution. A type annotation is necessary.

[Wesley Wigham (weswigham)]

The inferred type of '{0}' cannot be named without a reference to '{1}'. This is likely not portable. A type annotation is necessary. ?