Repository navigation
Typescript custom paths aren't used by quickfix to import dependencies #36235
Description
TS Template added by Matt Bierner (@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 |
Activity
[-]Typescript custom paths aren't used to import dependencies[/-][+]Typescript custom paths aren't used by quickfix to import dependencies[/+]mjbvz commentedon Jan 14, 2020
Please try upgrading your workspace to use
typescript@nextby installing this extension. Once you install that extension and restart VS Code, do you still see this issue?Maryannah commentedon Jan 16, 2020
Matt Bierner (@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 commentedon Jan 18, 2020
Matt Bierner (@mjbvz) I can confirm that using the nightly build doesn't work (again, for a Nx monorepo)
olmobrutall commentedon Jan 18, 2020
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)
Similar results from Visual Studio Code 1.41.1
What I would the quick fix to produces is the simpler:
Maryannah commentedon Jan 18, 2020
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 commentedon Jan 20, 2020
Matt Bierner (@mjbvz) I have also just found out that importing interfaces with the nightly build imports with the following format :
14 remaining items
andrewbranch commentedon Sep 15, 2020
Ah, I didn’t notice there were submodules. That’s what I was missing. Let me take a look.
andrewbranch commentedon Sep 15, 2020
Olmo del Corral (@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:olmobrutall commentedon Sep 15, 2020
Without changing the order:
VS Code recognizes the The Framework (@framework), but doesn't use it by default when autocompleting and is also not the first option
VS 2019 doesn't recognize the The Framework (@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 The Framework (@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 The Framework (@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 commentedon Sep 15, 2020
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. Ben Lichtman (@uniqueiniquity) any ideas?
change order in 'paths' (not effect yet microsoft/TypeScript#36235)
change order in 'paths' (not effect yet microsoft/TypeScript#36235)
uniqueiniquity commentedon Sep 15, 2020
Hi Olmo del Corral (@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 commentedon Sep 15, 2020
Hi Ben Lichtman (@uniqueiniquity), thanks your your answer:
After setting this option, Visual Studio 2019 is able to find The Framework (@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
editorconfigor 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 commentedon Sep 16, 2020
That was fixed by #40253 for 4.1; you should see the correct behavior by using typescript@next.
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 commentedon Sep 16, 2020
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 asettings.jsonfile.uniqueiniquity commentedon Sep 16, 2020
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 commentedon Sep 17, 2020
With the nuget in myget.org works perfectly
Also autocomplete includes The Framework (@framework)
olmobrutall commentedon Sep 17, 2020
But in VisualStudio 16.8.0 Preview 3 the default is still "Always use relative paths" not "Automatically determine best import path"
uniqueiniquity commentedon Sep 17, 2020
That's correct - we haven't had the opportunity to make the change quite yet.