Typescript custom paths aren't used by quickfix to import dependencies

[Maryannah]

TS Template added by @mjbvz

TypeScript Version: 3.8.0-dev.20200115

Search Terms

• paths
• tsconfig

---

Issue Type: Bug

I am trying to be able to import my dependencies from another files with custom paths in Typescript.

I should note that I am using Nx to create a monorepository structure : https://nx.dev/angular. The notable point of that framework is that it create a tsconfig.json file at the root of the directory, and when an app is created, it also creates a tsconfig.json file for that app, that has the property "extends": "../../tsconfig.json" (the apps are located in in "apps" folder, and under their own folder).

I then add a library to my application : this is located into the "libs" folder at the root of the project.

The root TS config file is updated accordingly :

    "baseUrl": ".",
    "paths": {
      "@myapp/mylib": ["libs/mylib/src/index.ts"]
    }

When written by hand, VSCode is able to import the file and make the app work with the line

import { MyLib } from '@myapp/mylib';

The issue comes with the quick fix. It offers either of those, but not the custom path :

• ../../../../libs/my-lib/src
• ../../../../libs/my-lib/src/lib/my-lib

I have tried evrything I could think of, from restarting VSCode, to changing the import type in the settings, I even modified the app TS config file by adding the path manually in it.

I can't seem to find any answer to this issue online as well.

For the reproduction code, you run the following commands, assuming you have NPM :

npx create-nx-workspace@latest myworkspace
cd myworkspace
npm install --save-dev @nrwl/angular
ng g @nrwl/angular:application myapp
ng g @nrwl/workspace:lib mylib

(You can select all the default options for Angular, or even choose randomly)

Once done, create a random export in the "libs/mylib/src/lib/lib.ts", then in the "apps/myapp/src/app/app.component.ts", try to import that random export.

VSCode issue report generated data

VS Code version: Code 1.41.1 (26076a4de974ead31f97692a0d32f90d735645c0, 2019-12-18T14:58:56.166Z)
OS version: Windows_NT x64 10.0.18362

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz (8 x 2808)
GPU Status	2d_canvas: enabled flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled metal: disabled_off multiple_raster_threads: enabled_on oop_rasterization: disabled_off protected_video_decode: enabled rasterization: enabled skia_renderer: disabled_off surface_control: disabled_off surface_synchronization: enabled_on video_decode: enabled viz_display_compositor: enabled_on viz_hit_test_surface_layer: disabled_off webgl: enabled webgl2: enabled
Load (avg)	undefined
Memory (System)	15.88GB (5.62GB free)
Process Argv
Screen Reader	no
VM	31%

Extensions (11)

Extension	Author (truncated)	Version
increment-selection	alb	0.2.0
ng-template	Ang	0.900.4
xml	Dot	2.5.0
prettier-vscode	esb	3.18.0
terraform	mau	1.4.0
azure-account	ms-	0.8.8
vscode-typescript-tslint-plugin	ms-	1.2.3
angular-console	nrw	10.0.0
material-icon-theme	PKi	3.9.2
quicktype	qui	12.0.46
vscode-scss-formatter	sib	1.4.3

[mjbvz]

Please try upgrading your workspace to use typescript@next by installing this extension. Once you install that extension and restart VS Code, do you still see this issue?

[Maryannah]

@mjbvz using the nightly build completely numbs my IDE down : it doesn't recognize the imports anymore (at least for the Nx repository), meaning there is not quickfix available anymore.

Sorry for the answer delay, and sorry but I'm currently not able to test this on a "casual" repository. I will try to create one later on and see if the issue still persists, but for my original issue with Nx repo, it doesn't resolve it !

[Maryannah]

@mjbvz I can confirm that using the nightly build doesn't work (again, for a Nx monorepo)

[olmobrutall]

I will also be very interested in this feature, I tried configuring VS or VS Code following this suggestion https://twitter.com/drosenwasser/status/1218307554578558976?s=20 without luck.

This are the results from Visual Studio 16.4.1 and TS 3.7 when trying to use it from this file (tsconfig here)

//Visual Studio: JavaScript / TypeScript -> Formatting -> General -> Module Specifier Preference
//Automatically determine best import path 
import { FileEmbedded } from '../../../Extensions/Signum.React.Extensions/Files/Signum.Entities.Files';
//Use unqualified mofule names if possible
import { FileEmbedded } from '../Extensions/Signum.React.Extensions/Files/Signum.Entities.Files';
//Always use relative paths
import { FileEmbedded } from '../../../Extensions/Signum.React.Extensions/Files/Signum.Entities.Files';

Similar results from Visual Studio Code 1.41.1

//changing javascript.preferences.importModuleSpecifier
//auto
import { FileEmbedded } from '../../../Extensions/Signum.React.Extensions/ts_out/Files/Signum.Entities.Files';
//relative
import { FileEmbedded } from '../../../Extensions/Signum.React.Extensions/Files/Signum.Entities.Files';
//non-relative
import { FileEmbedded } from '../../../Extensions/Signum.React.Extensions/Files/Signum.Entities.Files';

What I would the quick fix to produces is the simpler:

import { FileEmbedded } from '@extensions/Files/Signum.Entities.Files';

[Maryannah]

I also have another issue, that might (or mightn't) be related to that : when using the Nx monorepo architecture, although the full repository is opened in the IDE, I an not able to import the library through the intellisense or the quick fix.

In order to make it work, I have to import it by hand once per file. Once done, the subsequent classes coming from the same library, are now available in the file that got at least one import by hand.

The same thing happens when I work in an Angular environment, with Angular Material (for instance) : if I don't import at least once a module from the library, there is no intellisense our quick fix.

[Maryannah]

@mjbvz I have also just found out that importing interfaces with the nightly build imports with the following format :

  import type { MyInterface } from "...";

[andrewbranch]

It looks like this was fixed in TypeScript 3.9.

[olmobrutall]

@andrewbranch using Visual Studio 16.7.2 and Microsoft.TypeScript.MSBuild 4.0.2 that's definitely not the case :

"@framework" should be used, this is the .tsconfig: https://github.com/signumsoftware/extensions/blob/master/Signum.React.Extensions/tsconfig.json

[andrewbranch]

@olmobrutall I checked out your southwind repo to try to get a repro, but couldn’t figure out how to get a clean TypeScript build on a Mac. The directories referenced in paths were empty, and there were no build instructions in the README. If you can send me a branch where the target files are checked in, I can take another look.

[olmobrutall]

The project is a mixture of c# and and typescript, but the generated files from c# to typescript are all committed.

Also Southwind requires git submodules from Framework and Extensions. Maybe you need to checkout submodules? https://stackoverflow.com/questions/3796927/how-to-git-clone-including-submodules

There is a kind-of README here: https://www.signumsoftware.com/en/DuplicateApplication

Anyway, the problem happens on Visual Studio 2019 editor, not sure if it can be reproduced in VS Code or VS for Mac.

I’ll check as soon as I’m at home.

Thanks for your time

[andrewbranch]

Ah, I didn’t notice there were submodules. That’s what I was missing. Let me take a look.

[andrewbranch]

@olmobrutall your "*" paths entry is preventing the others from working because it’s listed first and is catching everything. You need to move it to the end:

    "paths": {
      "@framework/*": [ "../Framework/Signum.React/Scripts/*" ],
      "@extensions/*": [ "../Extensions/Signum.React.Extensions/*" ],
      "*": [
        "../Framework/Signum.React/node_modules/@types/*",
        "../Framework/Signum.React/node_modules/*",
        "*"
      ]
    }

[olmobrutall]

Without changing the order:

VS Code recognizes the @framework, but doesn't use it by default when autocompleting and is also not the first option

VS 2019 doesn't recognize the @framework

Changing the order

After moving the "*" option to the last in both .tsconfig files (https://github.com/signumsoftware/southwind/blob/master/Southwind.React/tsconfig.json and https://github.com/signumsoftware/extensions/blob/master/Signum.React.Extensions/tsconfig.json)

Same, VS Code recognizes the @framework, but doesn't use it by default when autocompleting and is also not the first option

Same, VS 2019 still doesn't recognize the @framework

There are at least a few dozens of applications that are clones of Southwind, so fixing this issue will help us a lot.

[andrewbranch]

VS Code recognizes the @framework, but doesn't use it by default when autocompleting and is also not the first option

That was fixed by #40253 for 4.1; you should see the correct behavior by using typescript@next.

I’m not sure why VS has different behavior from VS Code here, though. @uniqueiniquity any ideas?

[uniqueiniquity]

Hi @olmobrutall,

We actually have a setting for this behavior in Visual Studio 2019. You can find it under Tools -> Options -> Text Editor -> JavaScript/TypeScript -> Formatting -> Module Specifier Preference.
When we added the setting, we set it to default to "Always use relative paths" to avoid disrupting existing expectations, but selecting "Automatically determine best import path" will cause it to have the same behavior as VS Code.

[olmobrutall]

Hi @uniqueiniquity, thanks your your answer:

After setting this option, Visual Studio 2019 is able to find @framework:

But is not the first option and also not the option that is automatically used when you autocomplete... will this also be fixed in 4.1?

Finally, to improve discoverability, is there a way to override the option you mention using editorconfig or something similar? ... Or maybe just change the default for everybody? Looks like "Automatically determine best import path" should be better for anyone to me.

[andrewbranch]

But is not the first option and also not the option that is automatically used when you autocomplete... will this also be fixed in 4.1?

That was fixed by #40253 for 4.1; you should see the correct behavior by using typescript@next.

Or maybe just change the default for everybody?

I think we’ve determined that the default should have been auto—it looks like it may have been overlooked when that setting was added.

[uniqueiniquity]

Unfortunately, this would have to be fixed in a future update of Visual Studio 2019, rather than TypeScript itself.
I've just been discussing with the team the possibility of updating the default to "Automatically determine best import path", but because we're often hesitant to change users' settings without them knowing, such a change would only apply to fresh installs of VS or when a user resets their settings.

If you'd like to share this setting amongst team members, you can export a .vssettings file with Tools -> Import and Export Settings; this particular setting would be part of All Settings -> Options -> Text Editor -> TypeScript Specific. That file can then be imported into editors to apply this and other settings without a reset or fresh install.
We didn't feel that it would be an appropriate setting to include in the .editorconfig - that file is best for editor-independent settings, whereas settings in Visual Studio 2019 are controlled in the way I've discussed above and in Visual Studio Code by a settings.json file.

[uniqueiniquity]

Also, I just noticed we hadn't been publishing nightly builds of Microsoft.TypeScript.MSBuild for the past month.
I've fixed that process and a new build with #40253 should be pushed soon to https://www.myget.org/feed/typescript-preview/package/nuget/Microsoft.TypeScript.MSBuild.

[olmobrutall]

With the nuget in myget.org works perfectly

Also autocomplete includes @framework

[olmobrutall]

But in VisualStudio 16.8.0 Preview 3 the default is still "Always use relative paths" not "Automatically determine best import path"

[uniqueiniquity]

That's correct - we haven't had the opportunity to make the change quite yet.