Repository navigation
importHelpers with symlinks breaks type resolution #29221
Description
Activity
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?
Wesley Wigham (@weswigham) I'm using Linux and F2FS, but I don't think it mattered.
Is F2FS a case-sensitive filesystem?
Wesley Wigham (@weswigham) According to Wikipedia, yes
Wesley Wigham (@weswigham) You can repro this by setting
useCaseSensitiveFileNamesof nodeSystem in tsc.js totrueSimilar 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.Reacted by Steve Fan, Vitalii and markovicdenisI 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.3to3.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!
We're having this problem with Bazel-built typescript as well. Bazel symlinks all the
node_modulesdirectories.Reacted by Joel Jeske, Tony Gentilcore, Ezekiel Warren, Cooper Bills, Mihail, Daniel Muller, Software Engineer and hiepxanhWell, 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-2742I'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 all3.3,3.3.3333and nightly3.4.0-dev.20190315versions.When you clone the repo, just run
pnpm installand go totest.tsfile. 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 errorNow, go to
tsconfig.jsonand comment either"declaration": trueor"importHelpers": trueline and restart VS Code. The error will go away when you comment either config option.The error also goes away when you import
Reactitself along withcreateContextfunction:
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.
Reacted by Martynas Žilinskas, Martynas Puskunigis, Eimantas Dumšė, ystl, Denis Jankelaic, Bartek Kus, Steve Fan, Victor Colombo, Joel, Ruslan Konviser and 4 moreReacted by amkazan21 remaining items
@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.
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)Reacted by Alex Szabo, Takumi Adachi, Sujoy Chatterjee, Israel Gboluwaga Arunah, runjuu, Francesc Rosas, Stefan Åstrand and Kipras MelnikovasI 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 ?
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.
- added 5 commits that reference this issue
on Oct 11, 2020 - added a commit that references this issue
on Oct 30, 2020 - locked as resolved and limited conversation to collaborators
on Oct 21, 2025
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 theimportHelpersoptions to false and re-run the installation again.Expected behavior:
When
importHelpersis true, it shouldn't break type inference like we should whenimportHelpersis false.Actual behavior:
When
importHelpersis true and the Types (@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/