importHelpers with symlinks breaks type resolution

Question

importHelpers with symlinks breaks type resolution

stevefan1999-personal opened this issue 6 years ago · 31 comments

stevefan1999-personal commented 6 years ago

TypeScript Version: 3.2.2

Search Terms:
type symlink importHelpers pnpm

Code
https://github.com/stevefan1999-personal/gqlify/tree/patch-pnpm-tslib

Reproduction:
This is a little bit complicated, you will need to clone the repo I provided and checkout the branch, then run pnpm install, and then please flip the importHelpers options to false and re-run the installation again.

Expected behavior:
When importHelpers is true, it shouldn't break type inference like we should when importHelpers is false.

Actual behavior:

error TS2742: The inferred type of '...' cannot be named without a reference to '...'. This is likely not portable. A type annotation is necessary.

When importHelpers is true and the @types directory is a symlink.

Related Issues:
pnpm/pnpm#1375

Extra Stuff:
Although it is application-specific (Lerna with NPM/Yarn works fine on this), I do think this should be handled correctly regardless of any layers of symlinks.

PS:
tsc output observation diff: http://www.mergely.com/a6N4kOW3/

Answer 1 · 2019-01-03T19:25:28.000Z

I can't seem the repro the issue with the steps provided (builds fine both ways) - what platform and filesystem case-sensitivity are you on?

Answer 2 · 2019-01-04T10:29:11.000Z

@weswigham I'm using Linux and F2FS, but I don't think it mattered.

Answer 3 · 2019-01-04T16:14:07.000Z

Is F2FS a case-sensitive filesystem?

Answer 4 · 2019-01-04T16:46:08.000Z

@weswigham According to Wikipedia, yes

Answer 5 · 2019-01-04T17:24:45.000Z

@weswigham You can repro this by setting useCaseSensitiveFileNames of nodeSystem in tsc.js to true

Answer 6 · 2019-01-17T08:56:54.000Z

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.

Answer 7 · 2019-02-01T17:19:38.000Z

I ran into this issue as well. My project was built with Bazel.

A few snippets to reproduce the error:

import {Parser as ParserBase} from 'chevrotain'


const parser = createParser()

// @ts-ignore: TS2742
const BaseCstVisitor = parser.getBaseCstVisitorConstructor();

function createParser(): Parser {
    return new Parser()
}

class Parser extends ParserBase {
...
}

The compilation error after upgrading from ts 3.1.3 to 3.2.4:

src/ui/lib/dsl/langs/logi/semantic.ts:13:7 - error TS2742: The inferred type of 'BaseCstVisitor' cannot be named without a reference to '../../../../../../external/npm/node_modules/chevrotain/lib/chevrotain'. This is likely not portable. A type annotation is necessary.

13 const BaseCstVisitor = parser.getBaseCstVisitorConstructor();
         ~~~~~~~~~~~~~~

What I want is the ability to just mute this TS2742 error and make the code compile again.

I have tried adding // @ts-ignore, no luck.

Help needed. Thanks in advance!

Answer 8 · 2019-02-08T17:54:58.000Z

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

Answer 9 · 2019-03-15T11:06:18.000Z

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.

Answer 10 · 2019-03-15T12:58:36.000Z

An interesting detail: if I uninstall tslib, the error also disappears?...

Answer 11 · 2019-03-15T14:18:28.000Z

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

Answer 12 · 2019-03-19T12:23:32.000Z

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

Answer 13 · 2019-04-05T11:38:32.000Z

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.

Answer 14 · 2019-04-25T23:47:18.000Z

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.

Answer 15 · 2019-04-26T06:12:56.000Z

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.

Well, because "A type annotation is necessary", but this looks very magical-realistic to me since the type annotation is clearly traceable and "parsable" by human interaction, i.e. just hover on the problematic section/variable/expression, 99% of the time you can see the recognized types in your IDE.

Answer 16 · 2019-04-30T03:42:25.000Z

@weswigham I've attempted to create a repro over on #29808 (related issue)

Answer 17 · 2019-05-22T17:07:41.000Z

We are also facing this problem on our builds. Adding the type annotation manually is not viable since we are building third party code.

It works using regular Yarn but fails when we symlink the node_modules folder.

Answer 18 · 2019-06-20T22:25:23.000Z

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

Answer 19 · 2019-06-26T04:15:22.000Z

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

Answer 20 · 2019-07-17T11:48:41.000Z

@weswigham I still encounter the issue in 3.5.3

Answer 21 · 2019-07-24T20:10:51.000Z

I'm also having the same issue with a lerna monorepo and @types:
typescript@3.5.3 and typescript@next have the issue
typescript@3.1.6 is the last prodution release that works

3.2.0-rc also seems to be fine though
3.2.0-dev.20181110 seems to be fine
3.2.0-dev.20181111 seems to be broken

Answer 22 · 2019-07-24T20:21:19.000Z

@mrschofield if you can isolate how lerna's setting up the symlinks in your project and what structure of imports/types you're using to trigger the error, that'd be great. Although this issue was just about projects where setting importHelpers broke the ability to emit declarations (so it worked if that wasn't set) - if that's not the case for you, a new issue may be pertinent.

Answer 23 · 2019-07-24T22:51:29.000Z

@weswigham what about my repro of this issue described here #29808 (comment) ? Should I open a new issue?

That still exposes this issue and unfortunately #31571 did not fix.

Answer 24 · 2019-07-29T20:20:12.000Z

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

Answer 25 · 2019-08-01T19:40:20.000Z

I have similar problems with trying to setup build based on project references and been able to fix them by creating so called solution config where i reference all modules in monorepo and also exclude all files from compilation. Think that in this case only referenced modules and their deps are involved in resolving types by ts.

tsconfig.solution.json

{
    "exclude": [
        "**/*"
    ],
    "references": [
        {
            "path": "packages/moduleA"
        }
    ]
}

then compile project with command tsc -b ./tsconfig.solution.json

Answer 26 · 2019-08-06T08:40:01.000Z

I have this problem as well on multiple projects that appeared when upgrading from angular 7 to angular 8 (TS 3.1.6 to TS 3.4.5).
We have no symlinks and the issue only occurs when building with angular. A tsc build does not result in an error and there are no errors displayed in VS code.

Answer 27 · 2019-08-14T19:30:15.000Z

This issue is really annoying! Why is closed?

Answer 28 · 2019-08-15T02:16:12.000Z

@nthypes because the TS team is so naively thinking it's finally put a nail in the coffin. we still need more regression test to handle this.

Sadly I'm still in work and the university semester is going to start I probably had no time to handle this for everybody.

Answer 29 · 2019-08-19T09:55:16.000Z

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)

Answer 30 · 2019-09-08T22:46:26.000Z

I have this problem as well on multiple projects that appeared when upgrading from angular 7 to angular 8 (TS 3.1.6 to TS 3.4.5).
We have no symlinks and the issue only occurs when building with angular. A tsc build does not result in an error and there are no errors displayed in VS code.

@Roaders I'm having the same problem. Did you manage to find a solution ?

Answer 31 · 2019-12-07T08:06:08.000Z

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

Same here, downgrading to 3.1.3 did it. VSCode auto import functionality works again in TS files.