55

I created a custom npm library that is used in some root projects. This library is written in TypeScript. All sources are under a /src folder.

The tsconfig.json of the library contains those compiler options : 

"sourceMap": true
"outDir": "dist"

The package.json file contains : 

"main": "dist/src/index.js",
"typings": "dist/src",
"files": [
  "src",
  "dist"
],

In the end, the generated package contains the generated .js files, the d.ts files and the .ts source files :

- package.json
- /dist (`.js` and `d.ts` files)
- /src (`.ts` files)

In a root project where this custom library has been installed, I'm then able to add a breakpoint on a line calling a function imported from the library and stepping into it to debug its code, all in TypeScript. This is great!

But, in Visual Studio Code, when I CTRL-Click on a function imported from the library, without debugging, it leads me to the d.ts type definition file. I would prefere it to lead to the .ts source file! The way it is currently, I have to browse by myself to the /src folder of the library, under /node_modules, if I need to see the actual source code.

Is there a way to go to the TypeScript source file directly in VSCode, instead of the type definition file?

Heretic Monkey
  • 11,687
  • 7
  • 53
  • 122
electrotype
  • 8,342
  • 11
  • 59
  • 96

4 Answers4

41

Since Typescript 2.9 it is possible to compile your library with the declarationMap flag

./node_modules/typescript/bin/tsc -p . --declarationMap

Doing so creates a declaration map file (dist/ActionApi.d.ts.map) and a link to the map at the bottom of the corresponding d.ts file

//# sourceMappingURL=ActionApi.d.ts.map

When VSCodes encounters such a declarationMap it knows where to go to and leads you directly to the source code.

c_froehlich
  • 1,305
  • 11
  • 13
  • 7
    Wonderful!! We added `"declarationMap": true` to `tsconfig.json` and it works indeed... Thanks! – electrotype Jul 10 '18 at 19:51
  • What about a javascript node module with index.d.ts and jsconfig.json as a root? There is a way to add a declaration map? I'm interested to debug the odic-client module github.com/IdentityModel/oidc-client-js – blow Dec 21 '19 at 12:19
  • FYI, I am adding type definition files by hand, and using tsconfig to type check those, this does not work for my use case – gaurav5430 Jul 19 '21 at 17:43
  • This does not appear to work at least not with linked packages. – Archimedes Trajano Jan 23 '22 at 22:34
9

Add "typescript.disableAutomaticTypeAcquisition": true to settings.

leonheess
  • 16,068
  • 14
  • 77
  • 112
andrewkslv
  • 1,279
  • 12
  • 14
7

Starting with TypeScript 4.7, there is a new Go to Source Definition command which does this. VS Code 1.68 (May 2022) includes it.

If you have an earlier VS Code version, you can still enable it by installing JavaScript and TypeScript Nightly and following its documentation:

To make sure you are using typescript@next:

  1. Open a JavaScript or TypeScript file in VS Code.
  2. In the VS Code command palette, run the TypeScript: Select TypeScript version command.
  3. Make sure you have Use VS Code's version selected
Alexey Romanov
  • 167,066
  • 35
  • 309
  • 487
  • See https://github.com/microsoft/vscode-docs/blob/vnext/release-notes/v1_68.md#go-to-source-definition v1.68 is adding a `go to source definition` command. – Mark Jun 07 '22 at 00:58
-2

When you debugging, you actually fall to actual js, that has source maps. So, you feel like falling to typescript sources.

But TypeScript and VSCode know nothing about sources of the library. When TypeScript looking for the imported library, it search for package.json, then looks for the field "typings", and uses file specified there.

There is a reason, why libraries provide d.ts and .js for TypeScript, but not sources itself. If the library would provide sources, then you will need to compile them. It is strange and not efficient because:

  1. Every user of the library will burn their processor to compile all the libraries he depends on.
  2. User will change the content of the node_modules during compilation
  3. User will get a problem like this

That's why, all libraries shipped already compiled to js, with .d.ts declarations.

If you really want to see library sources (by the way, for what?), then just copy library sources to your src dir, and remove it from dependencies.

dominik
  • 5,745
  • 6
  • 34
  • 45
Pavel
  • 2,602
  • 1
  • 27
  • 34
  • 4
    There are many reasons why I may want to see the library source. The first one that comes to mind is if the function is `async` and is called with `await`. In that case, I need to go to the source file to set a breakpoint inside the function because "step into" while debugging doesn't go in the function directly. I may also simply want to see the code I'm about to call! – electrotype Feb 09 '18 at 17:53
  • 1
    Setting breakpoints to external library and investigating its code is not normal any way I think. If library requres exploring its code, it has bad API thought. – Pavel Feb 09 '18 at 20:32
  • 3
    I find I want to see how libraries implement things fairly often, (among other times) specifically in the situation where the library is extensible and I want to see how the existing options have been implemented. (This came up for me yesterday with Jest: https://jestjs.io/docs/en/expect#expectextendmatchers, for instance.) – Katie Byers Mar 10 '20 at 14:55
  • when an SO question says "how do I do thing?" it's almost never valid to answer "you shouldn't want to do thing anyway." – Matt Korostoff Jul 19 '22 at 16:29