TypeScript: importHelpers with symlinks breaks type resolution

This issue is really annoying! Why is closed?

We are encountering a similar issue, using Rush with pnpm (which symlinks packages in node_modules). I believe this issue should be reopened.

@weswigham can this be reopened? The repro I’ve provided via this comment is still broken in 3.5.2

Well, I’ve not only encountered this thing, but got a minimal repro with the weird behavior hapening on 3 computers: https://github.com/DovydasNavickas/ts-2742

I’m just not sure whether this is a TypeScript or VS Code bug. Same thing happens in the latest stable and latest insider versions of VS Code with all 3.3, 3.3.3333 and nightly 3.4.0-dev.20190315 versions.

When you clone the repo, just run pnpm install and go to test.ts file. The error should be there:

The inferred type of 'TestContext' cannot be named without a reference to '.registry.npmjs.org/@types/react/16.8.8/node_modules/@types/react'. This is likely not portable. A type annotation is necessary. ts(2742)

If it’s not there, restart VS Code and you should see it at least then.

NB! If run the compiler with pnpx tsc, you will _NOT_ get an error

Now, go to tsconfig.json and comment either "declaration": true or "importHelpers": true line and restart VS Code. The error will go away when you comment either config option.

The error also goes away when you import React itself along with createContext function: import React, { createContext } from "react";

But then I get another error:

'React' is declared but its value is never read. ts(6133)

So yeah. Compiler does not complain about this, but VS Code does.

I’m getting the same error when using oclif to scaffold some code. Some of the generated code looks like this:

import {Command, flags} from '@oclif/command'

export default class Hello extends Command {
  static flags = { ... }
}

I get the following error: The inferred type of 'flags' cannot be named without a reference to '.registry.npmjs.org/@oclif/command/1.5.13/node_modules/@oclif/parser/lib/flags'. This is likely not portable. A type annotation is necessary.

However, adapting @jackTheRipper’s solution, I added an explicit type annotation like so:

import {Command, flags} from '@oclif/command'

export default class Hello extends Command {
  static flags: flags.Input<any> = { ... }
}

Adding the annotation made the error go away.

The reason this issue is closed is because there’s nothing actionable in the thread at this point, and what was actionable was fixed, best as could be observed - if you have a codebase that still has an issue on the latest builds, opening a new issue with a full set of reproduction steps (as these kinds of issues are super sensitive to compiler settings, host environment, and actual code layout on disk) would be useful and tracking down and squashing the bug.

But in many instances, seeing the error reported isn’t a bug - even in @simonfox’s example, it probably isn’t. Why, you ask? Because if TypeScript needs to load two differing versions of one of your dependencies (because you upgraded one dep that shared a different dep with you but did not update that secondary dep within yourself) and one of them is nested, while we can often typecheck in the face of that, thanks to structual checking, we definitely have no stable, safe way to say “the type at this position refers to the older version of the type that we found in the nested node module here”. We could only do one of two things - incorrectly map to the later version, hoping it’s close enough, or issue an error. We err on the side of caution. Having consistent versions of your dependencies is a good thing~ (and, failing that, I think you can override how we resolve the dependency in question with a path mapping to force us to, for example, always resolve to the root version even if node module resolution would normally choose a nested one)

We’re having this problem with Bazel-built typescript as well. Bazel symlinks all the node_modules directories.

Run into this with any pnpm monorepo using @types/ would be interested in any solution.

Got the same issue in my project. I resolved the error by being more explicit regarding the return type.

So instead of writing the following:

export const mapHTMLElementToSerializableTarget = (element: HTMLElement) =>
  mapHTMLElementToElementData(element);

I changed it to

export const mapHTMLElementToSerializableTarget = (element: HTMLElement): IPerryElementData =>
  mapHTMLElementToElementData(element);

Now it compiles with no tricks

I’ve got the same issue when running in a @microsoft/rush monorepo The inferred type of 'getUrl' cannot be named without a reference to '../../../../../../../common/temp/node_modules/reselect/lib'. This is likely not portable. A type annotation is necessary.ts(2742). I’m not a TS genius at all, so any help would be appreciated.

Similar problem here and I guess the reason is the same. Typescript 3.2.2. Downgrade to 3.1.3 and everthing is fine.

Works fine on Mac and Ubuntu but breaks on Windows, which is using NTFS for sure.

ERROR in components/empty/nz-embed-empty.component.ts(36,3): error TS2742: The inferred type of 'defaultSvg' cannot be named without a reference to 'D:/Developer/ng-zorro-antd/node_modules/@angular/platform-browser/platform-browser'. This is likely not portable. A type annotation is necessary.
components/empty/nz-empty.component.ts(34,3): error TS2742: The inferred type of 'defaultSvg' cannot be named without a reference to 'D:/Developer/ng-zorro-antd/node_modules/@angular/platform-browser/platform-browser'. This is likely not portable. A type annotation is necessary.
components/select/nz-select.service.ts(45,3): error TS2742: The inferred type of 'open$' cannot be named without a reference to 'D:/Developer/ng-zorro-antd/node_modules/rxjs'. This is likely not portable. A type annotation is necessary.
components/select/nz-select.service.ts(52,3): error TS2742: The inferred type of 'listOfSelectedValue$' cannot be named without a reference to 'D:/Developer/ng-zorro-antd/node_modules/rxjs'. This is likely not portable. A type annotation is necessary.
components/select/nz-select.service.ts(53,3): error TS2742: The inferred type of 'modelChange$' cannot be named without a reference to 'D:/Developer/ng-zorro-antd/node_modules/rxjs'. This is likely not portable. A type annotation is necessary.
components/select/nz-select.service.ts(69,3): error TS2742: The inferred type of 'searchValue$' cannot be named without a reference to 'D:/Developer/ng-zorro-antd/node_modules/rxjs'. This is likely not portable. A type annotation is necessary.
components/select/nz-select.service.ts(97,3): error TS2742: The inferred type of 'valueOrOption$' cannot be named without a reference to 'D:/Developer/ng-zorro-antd/node_modules/rxjs'. This is likely not portable. A type annotation is necessary.
components/select/nz-select.service.ts(113,3): error TS2742: The inferred type of 'check$' cannot be named without a reference to 'D:/Developer/ng-zorro-antd/node_modules/rxjs'. This is likely not portable. A type annotation is necessary.

Ooook. More info: I’ve been testing with --noEmit flag present, which is why I was not getting the error while running the compiler.

Turns out, when I removed the flag for outputs to be generated, I got the error here too.

I guess the declarations part is the one erroring out, isn’t it?

/cc @SeaRyanC