Go To Definition not working with allowJS: false option in tsconfig

[chrisdancee]

TS Template added by @mjbvz

TypeScript Version: 3.8.1-rc

Search Terms

• tsconfig
• go to definition
• allowJs
• paths

---

Issue Type: Bug

VSCode module imports within a Typescript project respect the tsconfig.json file. There is strange behaviour around setting allowJS: false within the tsconfig.json file.

Specifically, when attempting to cmd + click, Go to definition, or peek an imported file, certain filetypes do not work as expected.

It is my expectation, that VSCode should be unopinionated about the file types, and should still locate the file successfully, regardless of this config option.

The following are the test results from importing different file types (.ts, .tsx, .js, .jsx) into every other file type. For these tests, both relative and aliased imports were tested (defined in the tsconfig.json).

A Pass represents that cmd + click successfully directed to the file. A Fail represents that cmd + click did not go to the file, and would instead stay on the currently opened file.

A full list of tests as well as the reproducible example can be found in:
https://github.com/chrisdancee/-vscode-js-definition-bug

Javascript to any aliased Typescript import - Fails
Javascript to any aliased Javascript import - Fails

Javascript to any relative Typescript import - Passes
Javascript to any relative Javascript import - Passes

Typescript to any aliased Typescript import - Passes
Typescript to any aliased Javascript import - Fails

Typescript to any relative Typescript import - Passes
Typescript to any relative Javascript import - Fails

VS Code version: Code 1.42.0 (ae08d5460b5a45169385ff3fd44208f431992451, 2020-02-06T10:51:33.119Z)
OS version: Darwin x64 18.7.0

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-8559U CPU @ 2.70GHz (8 x 2700)
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: unavailable_off 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)	2, 2, 2
Memory (System)	16.00GB (1.86GB free)
Process Argv
Screen Reader	no
VM	0%

Extensions: none

[mjbvz]

Someone on the TS team will have to confirm this, but I think what you describe is the expected behavior.

If allowJS is false, then JS files will not be considered part of the project. This means when you open a JS file, the paths config does not apply to it. Similarly, TS files cannot import js files (this results in a compile errors when using tsc if you enable strictNullChecks)

It would likely be confusing if go to definition worked in cases like this where the imports are not actually valid

[chrisdancee]

@mjbvz Thanks for looking into this. Personally I don't see why VSCode would be so tightly coupled to TS in this respect. I would still expect cmd + click to work regardless as it is then down to the developer, and not the tooling as to how their project is set up.

If this is the case however, I would still expect consistency between Javascript relative and aliased imports. In the repo provided, you can cmd + click from any JS file to a relatively imported TS or JS file. However if you instead import that file using an alias, this no longer works (but only as long as allowJS is set to false).

[RyanCavanaugh]

This is the intended behavior because we assume that configuration by users is done so on purpose and that we should honor that configuration.

When you're in the JS files, you're in an "implicit project" that is formed by the imports of that file.

[typescript-bot]

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.