Repository navigation
Intellisense cannot find referenced projects in VS, even after successful build #43375
Description
Activity
Ben Lichtman (@uniqueiniquity) Any thoughts on when you can get around to this? Some members of our team on newer VS versions can't get Intellisense for any modules, whether in the current project or a dependent project, which is hampering our work a fair bit.
Mark Boyall (@markboyall) Thanks for reporting this! I will aim to take a first look into this next week.
Please feel free to ping me again at the end of the week if I don't get back to you.Here's what's happening:
Your project reference is set up correctly, and the .d.ts files do have the correct names.
However, there's some ambiguity around the module specifiers that's giving you trouble.Within the context of the
Frameworkproject, you're able to import between modules with relative paths (e.g.import { TypeTagged } from "Framework/TypeTagged";).
Because you havemodule: "amd'andoutFileset, you produce a declaration file that defines the moduleFramework/Classfor the file./Framework/Class.ts.Therefore, the build performed when invoking TSC on the
Serviceproject succeeds, because it references the declaration file emitted fromFramework, which defines a moduleFramework/Class.However, when loading your projects, the language service skips over this declaration file and instead directly references the source files in the
Frameworkproject (e.g.Class.ts). In this scenario, there is no module defined calledFramework/Class, and you get an IntelliSense error.To workaround this issue, you can set up path mapping. In the project you provided, I added the following to the
Serviceproject's tsconfig:"paths": { "Framework/*": ["../Bluewire.Epro.Modern.Framework/Framework/*"] }
This instructs TypeScript to consider any non-relative module import starting with
Framework/to be treated as a relative module import from the Framework directory of the Framework project, thereby allowing it to properly find the module's file and fix the error. Furthermore, the JS code you get after building and adding an import toFramework/Actionis as you would expect (I think, I'm not an expert in AMD):define("App/Page/PageClass", ["require", "exports", "Framework/Action"], function (require, exports, Action_1) { ... }
I think this path mapping configuration should fix your issue.
Sheetal Nandi (@sheetalkamat) should we expect this to work in the language service without path mapping? That is, should we expect the language service to know that the
Frameworkproject exports an AMD module at runtime calledFramework/Classeven if the declaration file isn't included in the consuming project?I would expect that the language service should always figure out the same module names given the same tsconfig and source files as the build. I'll attempt the pathmapping you suggested and report back.
Ben Lichtman (@uniqueiniquity) This worked mostly for us. However adding the path mappings altered the output file order. We have an include which specifies files in specific orders, but this is no longer honoured after adding the path mappings.
"include": [ "App/Require.ts", "App/**/*.ts", "Dependencies/**/*.ts", "Specs/**/*.ts", "Dependencies/*.d.ts" ]Now, a root-level file is emitted before App/Require.ts, not after. Luckily we don't really need that file so I simply removed it, therefore this fix is still a substantial improvement for us, but it would be good to know whether the include order can be depended upon or if we need to make a build step to ensure that things are built properly.
I had investigated this a bit but didn't spend time on this since this is low usage area esp when using with project references.. It will involve making compiler aware that the source files also act as ambient module in this mode.
Also note that in most cases the path mapping or some such thing already exists ..
In general we guide people to write imports that work at runtime and then set compiler options that make it work. This kind of falls in similar category for now. We probably should create a issue tracking this and see how much upvotes it gets before spending time on this.
You always have option to setdisableSourceOfProjectReferenceRedirector add path mapping as a work around hence we need some input on how many people are really facing this before we spend time on this.That all makes sense to me. I was not sure whether or not to recommend
disableSourceOfProjectReferenceRedirectbecause I had not previously heard of that addressing correctness issues.It sounds like path mapping addressed the core issue here. Sheetal Nandi (@sheetalkamat) can you speak to Mark's question about the include order impacting the order of files emitted in the outfile? Do we make any guarantees about the order in which we concatenate output in the outfile? Mark Boyall (@markboyall) let me know if I'm misrepresenting the issue.
Order of files is same as your file order.. you can see that by passing
--listFilesor--explainFiles. There is no other guarantee on the file order.Sheetal Nandi (@sheetalkamat) I feel like you're viewing this from a weird perspective. It's not a new compiler feature, as the compiler already implements it, which is used when building. It's just a question of properly sharing that implementation between the language service and the compiler, which will avoid future cases where the language service does things differently to the build regardless of the specifics.
- assigned and unassigned
on Aug 10, 2021
🔎 Search Terms
intellisense references
🕗 Version & Regression Information
Typescript Version: 3.9.2 and 4.2.3 with Visual Studio 16.5.4 and 16.9.2
These are the VS/Typescript versions we have access to; our codebase would not build on an older version of TS.
⏯ Playground Link
As an intellisense issue in VS, the Playground is not really relevant here.
💻 Code
See https://github.com/markboyall/typescript-intellisense-break-repro
🙁 Actual behavior
In this minimal sample, see PageClass.ts. The Class import has no Intellisense support.
Intellisense cannot locate any modules in the referenced projects. Even after running the build and restarting VS, Intellisense is not supplied for the projects. Note that in the actual build this succeeds without error which I feel eliminates any potential of the tsconfig being incorrect.
🙂 Expected behavior
As #32028 is resolved, expect that when opening VS, intellisense is supplied for all modules. Or at the very least, this should begin working when the build is run (not unreasonable as some of our code is generated in MSBuild so Intellisense can't be expected to supply it before that; however this does not apply to the minimal sample).
I've manually verified a few things like that the .d.ts files are in the right place with the right name, and contain the right modules (would have expected the build to fail if these do not work anyway).
Not sure what extra information can be supplied here.