Auto import in Visual Studio Code only offering absolute path with Lerna subpackages in TypeScript

Question

For some reason, very recently my Visual Studio Code changed and started only offering absolute imports from the sub-package level with my Lerna packages, for example:

As you can see, the auto import is suggesting the @package/server/src/database path to the file when it should just be ../database as the file being edited is within the same package and is just one folder below the file containing the database variable I'm trying to use.

Is this a bug or configuration issue?

I've set my Import Module Specifiersetting for TypeScript in Visual Studio Code to all three options (auto, relative, and absolute) and none of them seem to make any difference.

Sinatra

I'll play with this if you set up a repository that I can clone to reproduce the problem. (I don't want to spend the time to try to set up a project like yours by myself only to potentially fail to reproduce the problem.) – Fronniah

Fwiw, at least one user has importModuleSpecifier set to relative in workplace and user files and it still imports with a full pat -- edit: this question suggested TS version -- there, a different version and issue -- could cause weirdness. Changing from TS 2.3.2 to 3.4.5 resolved this issue for me. /shrug – Kolinsky

Answer 1

In Visual Studio Code, menu File → Preferences → Settings → User Settings,

"typescript.preferences.importModuleSpecifier": "relative"

It works fine for me. It imports

import { RegistrationComponent } from '../../abc-modules/registration/registration.component';

in place of

import { RegistrationComponent } from 'app/abc-modules/registration/registration.component';

Diastyle

Thank you! When it's set to auto, it seems to change between using relative and absolute. – Glynda

I will pointout something: It is much better to have absolute path but starting from source dir (src/) like "import .. from "my-module/bla/bla/ClassName.js" because that approach will let You move packages and classes without changing imports. So You should avoid relative paths. – Deni

John Tribe's advice is legit with Vanilla JS. However I use TypeScript with "src" folder for TS and "dist" folder for transplied JS, so absolute path causes runtime error. – Overblown

amazing solution. @hirikarate, do your self a favor, stop using abs paths. the ecosystem does not fully supports it (including the IDEs). I spent 6 months to make it work. total waste of time – Sorus

JavaScript › Preferences: Import Module Specifier Preferred path style for auto imports. --> relative (Also, for jest testing, absolute paths break the test suite @JohnTribe.) – Dhoti

If it's not working: Note that you need to change the Typescript > Preference, not Javascript > Preference – Bertabertasi

Did anyone tell you if this is more beautiful? – Manche

There is also "project-relative" now, which makes it only prefer the relative import from within the same project. Useful for us with an NX monorepo setup, using tsconfig paths. Just using "relative" made vscode suggest relative imports instead of our configured paths. – Fredrika

Answer 2

In Visual Studio Code, menu File → Preferences → Settings → User Settings

search by importModuleSpecifier

Chuffy

It's works for me. Remember this tip works only typescript. You need the same steps to works do .js files – Playpen

Oh it's doing shortest for default! I could not figure out why some imports were /app and some were ../ That's a good brainteaser. I failed. – Botfly

+ better to use "typescript.preferences.importModuleSpecifier": "project-relative" – Tavey

Answer 3

My problem was that I had the baseUrl option set in my tsconfig.json file.

{
  "compilerOptions": {
    "baseUrl": ".", // remove
  },
}

After removing the option; VSCode immediately started importing via the relative path. The benefit of this method is that you can keep the VSCode option importModuleSpecifier set to shortest and relative path importing will still work.

Diaz

This was the most acceptable solution in my case as I wanted to keep using my webpack aliases for imports, and other solutions did cause aliases to stop getting suggested. – Aphelion

Removing baseUrl might not be a good solution, because you might want to keep it for other imports. Unless you want to disable all absolute imports. – Ataliah

Answer 4

I landed here from Google and had the opposite problem. My Visual Studio Code instance always imported the relative path even though it was from a different Lerna package.

It turns out that I simply forgot to add the package that it was wrongly importing to my consuming package’s package.json file.

Now, everything works as expected.

Declarative

Similarly, using NX and tsconfig paths, we fixed that by using "project-relative" as the importModuleSpecifier. Using just relative changed the other project's import to relative as well which is of course not what we wanted. "project-relative" works great though. – Fredrika

Answer 5

You might need a combination of baseUrl and paths.

tsconfig.json

  "compilerOptions": {
    "baseUrl": "./",
    "paths": {
      "holograph/src/*": ["src/*"]
    },
  }

VSCode settings

"typescript.preferences.importModuleSpecifier": "non-relative" // or "shortest"

My folders are like this. When I am in apps/app, I can auto-import in VSCode from packages with from 'holograph/src/ui/...'. But when I am in packages/holograph ui components, for a reason I haven't yet discovered, it auto-imports from src/ui, which gives a build error. I had to manually import from the package path hologrpah/src/ui. Doing the above paths import re-map fixed VSCode auto-imports.

node_modules
apps (next.js applications)
 ├── app
 |   └── pages
 ├── operator
 ├── storybook
packages (shared components & libraries)
 ├── holograph
 |   └── src
 |       └── ui
 ├── tsconfig
 ├── eslint-config-holograph
...

---

PS: This worked too, but I am not sure how valid this is. Basically setting the baseUrl one folder up. 🤷‍♂️

  "compilerOptions": {
    "baseUrl": "../",
    },
  }

Hardee

Finally!!! This VSCode settings It does not appear anywhere! – Bogusz

@Bogusz Duuuuude, hell yeah!! I spent like a month manually fixing all imports, occasionally searching for a solution that didn't exist. Then I got fed up and spent two days figuring this out. Such a relief. – Hardee