Intellisense cannot find referenced projects in VS, even after successful build

[markboyall]

🔎 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.

[markboyall]

@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.

[uniqueiniquity]

@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.

[uniqueiniquity]

@markboyall

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 Framework project, you're able to import between modules with relative paths (e.g. import { TypeTagged } from "Framework/TypeTagged";).
Because you have module: "amd' and outFile set, you produce a declaration file that defines the module Framework/Class for the file ./Framework/Class.ts.

Therefore, the build performed when invoking TSC on the Service project succeeds, because it references the declaration file emitted from Framework, which defines a module Framework/Class.

However, when loading your projects, the language service skips over this declaration file and instead directly references the source files in the Framework project (e.g. Class.ts). In this scenario, there is no module defined called Framework/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 Service project'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 to Framework/Action is 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.

@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 Framework project exports an AMD module at runtime called Framework/Class even if the declaration file isn't included in the consuming project?

[markboyall]

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.

[markboyall]

@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.

[sheetalkamat]

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 set disableSourceOfProjectReferenceRedirect or 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.

[uniqueiniquity]

That all makes sense to me. I was not sure whether or not to recommend disableSourceOfProjectReferenceRedirect because I had not previously heard of that addressing correctness issues.

It sounds like path mapping addressed the core issue here. @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? @markboyall let me know if I'm misrepresenting the issue.

[sheetalkamat]

Order of files is same as your file order.. you can see that by passing --listFiles or --explainFiles. There is no other guarantee on the file order.

[markboyall]

@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.