• VSCode Version: 1.46.1
• OS Version: macOS Catalina
• Does this issue occur when all extensions are disabled?: Yes

TLDR; When writing a Typescript package to be consumed by both Javascript and Typescript, "Go to definition" works for one or the other but not for both.

Problem 1

Steps to Reproduce

1. Given a NPM package that contains type declarations (.d.ts) and no sourcemaps.
2. When working in a Typescript or a Javascript project importing this package, if I ⌘+click, I am taken to the type declaration. However, I would expect to be taken to the source file and would expect to be taken to type declarations file if I click "Go to type definition".

Current solutions

• If the module is written in Javascript: Add sourcemaps.
• If the module is written in Typescript:
  • Removing type declarations from the package solves the issue for Javascript projects but it means the package is no more compatible with Typescript projects! So this is not a viable solution.
  • Adding sourcemaps along with Typescript sources, leads to Problem 2 below.

Problem 2

Steps to Reproduce

1. Given a NPM package that contains its Typescript source, compiled Javascript, type declarations and sourcemaps.
2. When working with a Typescript project that imports this package, if I ⌘+click, I am taken to the source file in Typescript. All is good as expected.
3. When working with a Javascript project that imports this package, if I ⌘+click, I am still taken to the Typescript source file. However, this is not an expected behavior as I am coding in Javascript, so if I want to debug the code, I'd be lost and have to learn Typescript and setup a Typescript compiler.
   The expected behavior should be to take me to the compiled Javascript (which is what I am actually importing in my project).

Currently, there is no way to control this behaviour, because VS Code probably uses the same algorithm to detect type declarations for Javascript and Typescript.

Possible solutions

1. VS Code's responsibility: Detect if the project is Javascript and if the source file being taken to is Typescript, then ignore typings. This has the advantage of requiring zero configuration.
2. Package publisher's responsibility: Introduce a typescript entry in package.json to include type declarations (and maps) to be used only for Typescript. This has the advantage of letting the package publisher decide what they want to do instead of the consumer.
3. Package consumer's responsibility: Do not pick up type declarations if they are specifically excluded in jsconfig.json

   {
     "exclude": ["./node_modules/npm-package/types"]
   }
   

4. Package consumer's responsibility: Introduce a new jsconfig.json entry useTypeDeclarations that can be set to false.

Current alternative solution for Problem 1 & 2

1. The package publisher shall create two subfolders, one for type declarations and one for the compiled Javascript code
2. The package consumer must import directly the subfolder containing the code instead of the generic package name

package.json

...
"name": "npm-package",
"types": "types/index.d.ts",
"main": "js/index.js",

Project code

import { x, y, z } from "npm-package/js";

This solution has a few downsides that I am aware of:

• This is not a common way of consuming NPM packages
• In the case of hybrid packages that supports several module types (CommonJS, ES6, etc.), it means the consumer has to choose which one to use while many tools (Webpack, Rollup, Parcel, ...) would have made the decision for him.

Related discussions

• googleapis/google-cloud-node#2867