TypeScript: Auto imports from referenced project not working until already imported once in project

Any update on this? How can Microsoft’s IDE (written in TypeScript!) not properly support Microsoft’s TypeScript 🤯

Project reference imports like using @ namespace only works when there is already an import using that path. Otherwise it defaults to relative paths. Very annoying to have to manually type it out initially everytime

Confirm. Autocomplete not working via references in tsconfig.json

demo: https://github.com/zerkalica/ts-references-autoimport-bug/tree/autoimport-no-ref

Currently autocomplete works only with includes (cpu eating on big projects) and via “types” in package.json.

Autocomplete doesn’t works with direct imports (without types in package.json)

Is there any workaround to this in the meantime? I read somewhere about setting baseUrl to the parent directory of both projects but it didn’t help

I found autoimports working quite reliably if top level tsconfig includes all files. It will be unused by any particular file or project having own local configuration, but magically enables autocomplete.

Also almost the opposite advice - do not reference workspace packages from a top-level config. Even for small projects it might take too much time to start language server, so you’ll be left with no support as-you-type.

Looks like src/environments/environment.ts and app.component.ts are part of separate tsconfig projects, although both of these project are both referenced by tsconfig.json.

Moving upstream to get the TypeScript team’s feedback on this behavior

So that the trick you should have your tsconfig-base as your tsconfig and put references aside (tsconfig.references.json) using them only inside particular packages.

I am not sure references are expected to work this way, but it works.

@andrewbranch

Sure, here’s a repo that has the issue.

This is based on a simplification of our own yarn monorepo. We’ve got a common project that contains stuff that’s shared between frontend and backend (the backend project is omitted), and a web project that references it via a @common alias. Each project has its own tsconfig.json. I believe this is pretty similar to the example repo posted above. To see the problem, hop into web/src/Helper.ts and try to use a “Quick Fix” to import square from the common repo.

This example repo doesn’t include any of this extra stuff because it suffices to show the issue, but for context, in our real repo web is a CRA-based Webpack app. We run it via yarn tsc --build --watch & react-app-rewired start (we run tsc separate because CRA’s setup doesn’t understand building projects). We want to import the compiled code in common/dist via an alias (e.g. import { square } from '@common/MyModule').

Our biggest issue is the one mentioned in the comment above - VSCode auto-import suggests relative paths to the original .ts file no matter what. There’s a few issues here:

• it leads CRA to barf because of the attempt to import a file outside of the project (this works fine with aliases, with some monkey-grease)
• we want to be importing the compiled .js file, not the original .ts file
• Depending on VSCode settings, it won’t even import the correct file.

What I mean by that last point is, if I try it with the “Import Module Specifier” preference set to “shortest”, it works (although with a relative path, which is still undesirable):

But if I set “Import Module Specifier” to “non-relative”, it curiously gives me:

Which is simply broken - an immediate compilation error.

It’s totally possible - and would be great if! - this is just a configuration issue on our part and there’s a different/better way to do it.

Thanks for your help!

any update here? my team would really like this issue fixed.