Allow configuration of NodeBuilderFlags.AllowNodeModulesRelativePaths for un-distributed mono repos

Search Terms

• AllowNodeModulesRelativePaths
• The inferred type of … cannot be named without a reference to …
• #29808
• https://github.com/microsoft/TypeScript/issues/30858
• https://github.com/microsoft/TypeScript/pull/27340

Suggestion

Allow the optional use of AllowNodeModulesRelativePaths during declaration creation

Use Cases

I understand why @weswigham added https://github.com/microsoft/TypeScript/pull/27340 and it is correct for most consumers, especially those that publish packages for consumption on NPM.

However, it seems like for npm style mono-repos where packages are only consumed locally and not published to a registry, it is valid to have seemingly non-portable TS references (lerna, pnpm, rush, yarn workspaces). A relative path to a node_module may still be valid as long as the structure stays consistent, which it does for this style of mono repo with a single node_modules directory.

I am using a mono repo managed by Bazel and rules_nodejs and users are experiencing issues with the creation of declaration files that otherwise would contain relative paths to node_module files. https://github.com/bazelbuild/rules_nodejs/issues/1013

(The conversation in https://github.com/microsoft/TypeScript/issues/30858 was helpful, however, it seemed to still be focusing on resolving portable types, which is only necessary when distributing the declaration files. If they are consumed locally, portability is not a concern.

Examples

I’m not sure the best way (or standard way) for these flags to be set, however, I imagine an entry in the TSConfig Compiler Options would make the most sense:

interface CompilerOptions {
  ...
+  allowUnportableDeclarationImports: true
} 

Currently I am patching Typescript to toggle on this behavior and it appears it is working just as expected.

typescript+3.7.3.patch.txt

Checklist

My suggestion meets these guidelines:

• This wouldn’t be a breaking change in existing TypeScript/JavaScript code
• This wouldn’t change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn’t a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript’s Design Goals.

[matthewjh]

@weswigham we would really appreciate your help in prioritising a proper solution for this. Yes, the d.ts files are intermediate artefacts as part of a larger incremental build.

FWIW we are trying to move our company-wide monorepo to bazel, and though we currently have a workaround in a patch provided by @flolu and @joeljeske, this is not really production-appropriate and we strongly feel this needs to be properly supported by vanilla tsc.

Note that:

1. This will affect anyone who uses bazel and the ts_library rule, AND who uses type inference.
2. This is fully reproducible in the official Angular repo, which uses bazel and ts_library. By checking out and changing the code so that tsc has to add an import for an inferred type, you will encounter the error. They seem to have either gotten lucky or deliberately worked around by avoiding any need for type inference, which I find very surprising. So - this is not a weird edge case-type issue, but affects existing consumers of tsc and bazel in large, popular codebases.

Thank you, and we appreciate the help.

[btakita]

It looks like this feature has been delayed. Are there any good workarounds other than sucking it up & dealing with thousands of failures individually by casting each failure with any type or explicitly typing each failure?

@RyanCavanaugh @weswigham I would prefer to expose internal types as I utilize both a set of monorepo open source libraries used by multiple monorepo private apps. Please take this issue seriously. It’s cost me > 10 hours of work so far in the middle of a large refactoring under pressure from a client.