types in transitive dependencies causing errors after upgrade from 3.1: The inferred type of ... cannot be named without a reference to

[ravenscar]

TypeScript Version: 3.4.3

Search Terms:
transitive dependency inferred type cannot be named without a reference
Code

Sorry that this is a Dockerfile, since the problem relates to multiple modules being installed as dependencies to each other it's difficult to express in a single piece of code. There's only 16 lines of code total, near as minimal as I could make it.

https://github.com/ravenscar/ts29221

docker build -t ts29221 https://raw.githubusercontent.com/ravenscar/ts29221/master/Dockerfile

Expected behavior:
tsc can compile the code

Actual behavior:
tsc fails with the messge:

src/index.ts(3,14): error TS2742: The inferred type of 'thingyTuple' cannot be named without a reference to '../../b/node_modules/ts29221-a/dist'. This is likely not portable. A type annotation is necessary.

This used to work fine in TS < 3.2 and seems to have broken since then, looking at the breaking changes I can't see anything mentioned which would apply here.

At first we thought we were experiencing issues due to symlinks created by lerna bootstrap and wanted to create an extremely minimal reproduction based on #29221, however we discovered that symlinks aren't the problem and have produced a Dockerfile to show that:

docker build -t ts29221 https://raw.githubusercontent.com/ravenscar/ts29221/master/DockerfileNoSymlinks

We also have a Dockerfile showing this working in 3.1:

docker build -t ts29221 https://raw.githubusercontent.com/ravenscar/ts29221/master/Dockerfile31

What happens here is that module ts29221-a exports a type definition, module ts29221-b uses that type definition in the return type of a function, then module ts29221-c uses that function to assign a value to a const.

This is using the new build system, with refs in the tsconfig, and is bootstrapped by lerna.

What is happening here is that when tsc is compiling ts29221-c it imports the types from ts29221-b which in turn imports them from ts29221-a. It then sees that they types are at a relative position of ../b/node_modules/ts29221-a/dist compared to ts29221-c's package.json.

They are actually also at node_modules/ts29221-b/node_modules/ts29221-a/dist relative to ts29221-c's package.json.

This is for example where they may be if they were installed by a package manager that didn't flatten dependencies (e.g. npm2 or pnpm).

The only way around this is for c to somehow know that b uses a and to add a as a direct dependency of c. Then to import the used type definition from a before importing b, even though c doesn't directly use a (so will need a tslint:ignore too).

Or do something even worse such as put this workaround at the top of c/src/index.ts:

import * as _ from '../node_modules/ts29221-b/node_modules/ts29221-a';

I think it is unreasonable for modules to need to know the dependencies of any of their submodules when it comes to types, although that is what we are currently doing in dozens of places.

I understand that the module resolution shows that it will only go up for node_modules but it really seems like something went wrong here as this pretty much makes TS broken for monorepos that use symlinks, if this is intentional then it's hard to imagine how the new build/watch features (which are awesome BTW) are supposed to work when the ts module dependencies are multiple levels deep.

Related Issues:
#29221
#29808
#26985

[ravenscar]

FYI I have also create a fork of the lerna example from @RyanCavanaugh but with the code for the above modules: https://github.com/ravenscar/learn-a

It fails with the same error:

The inferred type of 'thingyTuple' cannot be named without a reference to '../../pkg2/node_modules/@ryancavanaugh/pkg1/lib'. This is likely not portable. A type annotation is necessary.

[arthur-chan-leapyear]

Having similar issues on my team when we're writing any new library. If I use some package, lets say, react-select, and react-select has type annotations from @types/react, then I will have to copy and paste any type signature that I use from react-select.

In this specific case, react-select lets you define some styles like such:

export const SelectStyles = {
control: (base: React.CSSProperties) => ({ ...base, minHeight: '32px', padding: 0, margin: 0 }),
  dropdownIndicator: (base: React.CSSProperties) => ({ ...base, padding: 4 }),
  clearIndicator: (base: React.CSSProperties) => ({
    ...base,
    padding: 4
  }),
  ...
}

In the latest Typescript, I need to also need to explicit declare the type of SelectStyles:

type StyleFunctions = {
  control: CSSPropertiesFn
  dropdownIndicator: CSSPropertiesFn
  clearIndicator: CSSPropertiesFn
  ...
}

export const SelectStyles: StyleFunctions = ...

This is a bit onerous, and feels like it's something the compiler should be able to generate in the worst case. Making @react/types a dependency of the package did not help, and I checked that the affected packages are using the same version of @react/types.

This is just one particular example. There have been others since upgrading past 3.1.

[Roaders]

We're getting many examples of this on multiple projects that we're updating to angular 8 (ans as a result TS 3.4)

[Roaders]

Although... Having said that I only get this problem when compiling using angular. It does not happen when I just use tsc

[leemhenson]

I see this in a monorepo that uses pnpm to link the packages together. Under Mac OS the project reports a few of these sorts of errors in files A and B, but if I build via a Ubuntu image in Docker then I see the error reported in files C and D. I can work around the issue by adding explicit types at each location mentioned in the errors.

[arthur-chan-leapyear]

We're currently intending to get around the error (in our HOCs) by using React Hooks instead of HOCs. But this doesn't help the folks who've got large codebases that need HOCs, or frameworks that are still using that paradigm.

[pauldraper]

This error started happening in 7a71887 by @weswigham.

It errors if "node_modules" appears in the generated import, as that will probably not work when the .d.ts files are distributed. This is controled by NodeBuilderFlags.AllowNodeModulesRelativePaths.

Another repo case: https://github.com/pauldraper/ts-infer-import

I ran into this with bazel-contrib/rules_nodejs#1013 .

The Bazel build tool doesn't give control over the file layout (makes dependency and heremiticity guarantees easier); so that project uses a path mapping to the location of node_modules. "*": "../some-dir/node_modules/*".

So the import from example-lib has types that produce imports from ../some-dir/node_modules/example-lib.

(Ideally, TypeScript would choose a non-relative path mapping here.)

Until TS 3.2, this was not a problem since Bazel users typically do not distribute their declarations via npm.

[weswigham]

Ideally, TypeScript would choose a non-relative path mapping here.

In such a scenario, a non-relative mapping does not yet exist as far as the compiler is aware. If A has B in it's modules folder, and B has C in it's modules folder, and generating the types for A ends up relying on types from C, there's no way to write a non-relative reference to that (since it's not in A's modules folder). Now, changing your code so it can be referenced in a non-relative way is usually pretty trivial, like adding a direct dependency between A and C, or by not needing to reference C by manually annotating with a type that you can name.

[pauldraper]

Correct. A non-relative mapping is not always possible.

In the repro case it was, but yes not generally.

The code first tries for a node_modules-based non-relative path, and then falls back to non-node_modules relative path, preferring relative.

In my case, Bazel was effectively trying to relocate node_modules via a * path mapping. Had it actually been real node_modules, it would have generated a non-relative path and succeeded. But it wasn't, so it didn't.

A "solution" for this case would be to try both node_modules non-relative and non-node_modules non-relative paths first. I say "solution" because IDK if it is the best approach. I think Bazel just needs to get more aggressive.

Could resolveModuleNames and resolveTypeReferenceDirectives hooks override the behavior of getSpecifierForModuleSymbol?