Typescript: Suggest relative paths when showing 'add missing import' code action

[AdamWillden]

The code action for adding missing imports currently provides a list of possible matches, but all seem to use absolute paths :

This will not work for my packages. I would like an additional option which uses a relative path from the current file (i.e. import { TreeNodeBase } from './tree-node-base';)

---

I'm sure this request must be somewhere in the 2000+ issues but multiple keyword searches has failed to return a result.

[mhegazy]

can you share your tsconfig.json?

[AdamWillden]

Sure, does that mean it should be supported by my using a rootDir removes that support??

{
  "compileOnSave": false,
  "compilerOptions": {
    "rootDir": "src",
    "outDir": "dist",
    "sourceMap": true,
    "inlineSources": true,
    "target": "es2015",
    "module": "es2015",
    "declaration": true,
    "importHelpers": true,
    "noImplicitAny": true,
    "removeComments": true,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "strictNullChecks": true,
    "forceConsistentCasingInFileNames": true,
    "baseUrl": "./",
    "paths": {
      "tslib" : ["jspm_packages/npm/[email protected]/tslib.d.ts"]
    }
  },
  "exclude": [
    "dist",
    "node_modules",
    "jspm_packages"
  ],
  "filesGlob": [
    "./src/**/*.ts",
    "./test/**/*.ts",
    "./typings/index.d.ts",
    "./custom_typings/**/*.d.ts",
    "./jspm_packages/**/*.d.ts"
  ]
}

[mhegazy]

I think this is caused by the baseUrl, i can not be sure until i look at the whole project.

baseUrl gets a preferential treatment, if the module is under the baseUrl it will always use the absolute path.

A possible fix here is to allow paths to be specified without an explicit baseUrl, with the value implicitly known to be ./, and then not using that in the code action. but this seems like a much bigger change.

[AdamWillden]

hmm, I'll try to see why I have it in my tsconfig. Hopefully I can remove it and get it working for my use-case...

[mhegazy]

hmm, I'll try to see why I have it in my tsconfig. Hopefully I can remove it and get it working for my use-case...

if you do, you will need to install [email protected] to your local node_modules instead of using path mapping.

[aluanhaddad]

I use a very similar configuration and I really like the current behavior.

With the possible exception of modules that are direct siblings of the current module, I find base URL rooted imports to be much more maintainable.

Sure, they lead to module specifiers that are sometimes a half-dozen characters longer than their relative ones would be, but they are easy to read, and they make reorganization painless.

I feel like it would be strange to introduce an implicit --baseUrl to support a code fix.

[rosieks]

I'm using JavaScriptServices template and in my case it adds incorrect import probably due to configuration of webpack but still in case if I want to add sibling React component that's in the same folder it adds:

import { LogsList } from 'ClientApp/logs/components/LogsList'

instead of just

import { LogsList } from './LogsList'

[whitecolor]

The problem is that it doesn't work well with node.js which can not be tuned (without hacks) to handle import paths.

And relative paths are often preferred.

[asvetliakov]

Any news? Autoimports in TS 2.6 are affected by this issue and totally unusable.

[mhegazy]

Ideally we do not break the existing use case of baseUrl, one proposal here is to use relative path as long as it is below the baseUrl. in other words, you never need to climb up to the baseUrl directory itself to reach the target, always below it.

[aluanhaddad]

I prefer the current behavior.

[weswigham]

Why not just provide both options in the code fix list? As far as the typesystem/binder is concerned, if the file is lookupable form either the relative or the absolute path, it's style choice as to which is the preferred result.

[andy-ms]

We can provide both but order them based on the heuristic.