Repository navigation
Find references even when TypeScript sub-projects not yet open #30823
Description
Activity
Confirmed with TypeScript 3.5.0-dev.20190407
Reacted by Dan Cecile and Julius WaltherThis is currently known issue in which if the file is not open or declaration maps are not present it cannot find all references in sibling projects. #28261 is wip for this but needs more work before can be merged in since we need to be smart about when to lookup symbol in other projects(as loading projects in most common scenarios is costly and can result in delay when someone does first time find all references)
Reacted by Dan CecileRyan Cavanaugh (@RyanCavanaugh) I believe the
Duplicatelabel is a mistake here.This blocks us from splitting our code into multiple smaller projects as (consistent!) renaming across the entire codebase is very important to us. We would love to have this feature!
#28261 is wip for this but needs more work before can be merged in since we need to be smart about when to lookup symbol in other projects(as loading projects in most common scenarios is costly and can result in delay when someone does first time find all references)
Personally, I will happily trade off performance for "Find all references" and "Rename symbol" that actually works.
In https://github.com/strongloop/loopback-next, we have configured TypeScript to treat the entire monorepo as a single project, so that we can use "Find all references" and "Rename symbol".
We also don't use declaration maps, therefore cross-project imports are resolved against the original TypeScript sources, not via.d.tsand.d.ts.mapfiles.This setup works pretty well for us and I am not aware of any performance or memory limitation when working in VS Code. If the performance of #28261 is similar, then I would happily accept it.
Why we want to migrate from our single-project setup to project references when VS Code experience is good now? The problem is that our build times are super slow. We are building each monorepo package independently, because each package has its own
outDir, e.g.packages/{name}/dist. Because cross-project imports are resolved against the original TypeScript sources, I suspect that the compiler is repeatedly parsing each TypeScript source file again and again for each top-level package depending on it.Anyhow. Is there a way how to finish #28261 sooner, possibly without performance optimizations and perhaps behind a new feature flag?
Reacted by rvion, Julius Walther, Biniam Admikew and LuděkI currently have a code base that uses composite projects and has 34 sub-projects.
Having to open all 34 sub-projects to "Find all references" is a little tiring =/
Reacted by Tom Medema, Devon Deonarine, Max Khokhryakov, Victor Glindås, Victor Glindås and HaoyeHi Matt Bierner (@mjbvz) Ryan Cavanaugh (@RyanCavanaugh) apologies in advance for the direct mention. Are there any plans to prioritise this?
We've recently migrated a very large frontend codebase to sub-projects, and opening files from each before finding references isn't feasible, so we seem to be stuck with grepping for now, or switching to IntelliJ which doesn't seem to rely on TS server to do the references.
Edit: I've just been pointed at #33287 so perhaps a fix is already in progress?
Reacted by Tomas BramboraReacted by Sam Cooke, Saxon Landers, Anton Sarmin, Boomer Truong, Wojciech Karaś, Tomek Modrzyński, Declan Vong, Vladimir Katushenok, Tomas Brambora, max-in-bc and 1 moreI have a similar problem in a case implementing scenario described in the project references documentation.
There is a root
tsconfig.json, referencing packages which are a set of composite projects (implementation and tests). In case there is notsconfig.jsonwith non-emptyfilesin a package, VS Code won't pick up the config for the files in the package.https://github.com/pablobirukov/vs-core-project-references
For what it's worth, in order to get this to work, we had to add a "solution"
tsconfig.jsonat the root of our repo that references all projects, as recommended in the Typescript handbook:Another good practice is to have a “solution” tsconfig.json file that simply has references to all of your leaf-node projects and sets files to an empty array (otherwise the solution file will cause double compilation of files). Note that starting with 3.0, it is no longer an error to have an empty files array if you have at least one reference in a tsconfig.json file.
We were able to automate generating this list using meta-updater. See our meta-updater config for more details
Reacted by Alex Treppass, JayDouglass, Pavlo B. and Michael JamesI did all, i created a root
tsconfigwithreferences, I settsconifgin all project withcomposite: trueand still I need to open project to use find references.I found a hack, I added
"files": ["./project1/tsconfig.json", "./project2/tsconfig.json"]to roottsconfigand it seems it force vscode to load alltsconfigand its working very well.Reacted by MTariqAzizReacted by Max Khokhryakov, Victor Glindås, Bruno Heridet and Mark- added a commit that references this issue
on Sep 20, 2026
From microsoft/vscode#65102...
It seems like with a multiple-tsconfig.json setup, VS Code can't find all references. (Even though technically all of them should be "joined" via a root tsconfig.json that uses project references.)
Here's a minimal repro of my setup: https://github.com/dcecile/typescript-references-test