Repository navigation
Type resolution in linked packages #32970
Description
Activity
If I'm not mistaken, this is incredibly annoying from our perspective, because as far as TS knows, you've loaded two copies of
typescript-fsainto the compilation - one inplugin-one's modules, and one inplugin-two's, and we're typechecking by loading both, as is appropriate for each use site. If a type at a position comes from the one which if not your immediate dep, you then get an error like this.Now, I thought we already had some fancy logic that unified dependencies that were exactly the same version (and maybe we are) - it's possible that logic is missing a bit of code to propegate its gleaned knowledge of the project paths into the specifier generation process.
Wesley Wigham (@weswigham) sorry can you clarify the following
If a type at a position comes from the one which if not your immediate dep, you then get an error like this
Here I am getting the error from a src file that is part of
plugin-onethat importstypescript-fsadirectly with no reference to anything fromplugin-two....which is different to the case you are describing?This was not an issue in
3.1.x- we started to experience on anything from3.2.xon. Maybe something with the unification logic got broken in there? Where might I find that logic if I wanted to have a look myself?Somewhere in
moduleNameResolver.tswe end up merging things with similar package ids (identically versioned packages found in different locations), I believe causing us to "forget" some of the paths the module could be found at by the time we're trying to generate a specifier inmoduleSpecifiers.ts.Reacted by Eric M. DantasSimon Fox (@simonfox) can you try to compile adding in tsconfig.json:
"incremental": trueAfter that, try to build. You should get the error,.
Now, try to build again without remove the .tsbuildinfo file, and check if compiles correctly.
I think this info can help us to find the real issue.
For some reason, after have the .tsbuildinfo file, project compiles normally, but not in the first build.
PS: Version used to reproduce this was 3.5.3
Reacted by Neale Upstone@nthypes I think that is just because you haven't made any changes between builds so the incremental build finds no work to do?
@nthypes I think that is just because you haven't made any changes between builds so the incremental build finds no work to do?
Nope, because in the first try no
distfolder is created, but in the second try thedistappears with transpiled files.@nthypes but this problem is in typings generation - you will get transpiled
.jsbut there is no.d.tsfor the files that caused errors (besides I get the transpiled js on the first run).With
"declaration": falseyou don't get the problem.This is happening to me as well
The inferred type of 'print' cannot be named without a reference to '@straw-hat/cli-next/node_modules/chalk'. This is likely not portable. A type annotation is necessary.// my print.ts file import chalk from 'chalk'; const colors = { highlight: chalk.cyan, info: chalk.blue, debug: chalk.gray, warning: chalk.yellow, success: chalk.green, error: chalk.red, line: chalk.grey, muted: chalk.grey, }; export const print = { colors, };
// my cli.ts file import { print } from '../print'; export class Toolbox { // it fails here public print = print; }
I did
yarn linkif that matters.I ended up disabling
declarationto turn it offSimon Fox (@simonfox) I am getting error trying to repro this when I try to install the dependencies:
c:\temp\repro-plugin-one>yarn yarn install v1.17.3 [1/4] Resolving packages... [2/4] Fetching packages... error Command failed. Exit code: 128 Command: git Arguments: ls-remote --tags --heads [email protected]:simonfox/repro-plugin-two.git Directory: c:\temp\repro-plugin-one Output: [email protected]: Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.- assigned and unassigned
on Sep 11, 2019 3 remaining items
- added a commit that references this issue
on Sep 23, 2019 Really hope this PR will fix this annoying issue.
I'm using Typescript 3.7.5 and I'm still facing this issue.
Wesley Wigham (@weswigham) mentioned:
[...] as far as TS knows, you've loaded two copies of
typescript-fsainto the compilation - one inplugin-one's modules, and one inplugin-two's, and we're typechecking by loading both, as is appropriate for each use site. If a type at a position comes from the one which if not your immediate dep, you then get an error like this. [...]That's pretty much what's going on for me. I have this
lib-corethat's used in a bunch of separated lower level applications that are used in some higher level applications. Now, everytimelib-coreis update I also have to update its version both in the other lower level applications as in the higher level applications. It's being incredibly annoying to do it by hand, especially because my team and I still have some other lower level applications to write, so it'll only get worse.Also, I can't set
declarationtofalsebecause I need the typings.I still face this issue as well......the linked PR has fixed it in the repro I supplied however our app still suffers this issue.
We still see the issue when the problematic package is at the same version across our linked packages.
Actually I've just modified the repro slightly and it does still exhibit this problem.
Sheetal Nandi (@sheetalkamat) Wesley Wigham (@weswigham) Ryan Cavanaugh (@RyanCavanaugh) can this be looked at again?Reacted by Eric M. DantasSimon Fox (@simonfox) This issue was fixed. Can you please open new issue with exact steps to repro the issue. We will investigate that one. Thanks
- locked as resolved and limited conversation to collaborators
on Oct 21, 2025
This is essentially a duplicate issue however there has been no response on the existing issues which have been incorrectly closed so I am opening again.
Related issues:
#29221
#29808
Merged PR which hasn't resolved the issue:
#31571
Problem occurs when using
yarn linkfor development purposes.Window 10 Pro v1903
Typescript 3.5.3
yarn 1.17.3
I've created a repro and described steps over on #29808 but basic steps are below
If you clone https://github.com/simonfox/repro-plugin-one and https://github.com/simonfox/repro-plugin-two and run
yarnfor both. Then runyarn linkin plugin two root, and then link one to the local two withyarn link plugin-twofrom one. Then you will see the issue in src/features/feature-one/actions.ts (you may need to reload the VS Code window after linking).This results in
error TS2742: The inferred type of 'actions' cannot be named without a reference to 'drive-common/node_modules/typescript-fsa'. This is likely not portable. A type annotation is necessary.UPDATE Should explicitly mention that this is in typings generation. With
"declaration": falsethis error does not occur.