1

I've this code, it's a react typescript project:

import { Trans, translate, InjectedTranslateProps } from 'react-i18next';

and then:

export const Home: React.SFC<InjectedTranslateProps> = props => (

When i click on webstorm on InjectedTranslateProps, it's take me to /node_modules/@types/react-i18next/src/props.d.ts

why is taking me to @types and not to 'react-i18next' package ? i mean all the links take me to @types and not the right folder for react-i18next in node_modules

so, everything pass by @types, and i's that library to connect it with the real package?

i don't need to see javascript code, just need to see if imports go first to the typescript file, and it's that file that do the work to import.

DDave
  • 1,400
  • 3
  • 16
  • 33
  • Possible duplicate of [How can I view original javscript library source code in VS Code and not the typescript version?](https://stackoverflow.com/questions/52464407/how-can-i-view-original-javscript-library-source-code-in-vs-code-and-not-the-typ) – Matt McCutchen Oct 11 '18 at 14:13
  • nope, i know where is the original code, the question is just to know the logic – DDave Oct 11 '18 at 14:24

1 Answers1

0

At runtime, your module loader will resolve the import directly to the real implementation. When the TypeScript language service sees an import, it only cares about the type information and not the implementation, so if the implementation file is a .js file and doesn't have a .ts or .d.ts alongside it, the language service will look for a .d.ts in a @types package. When you click on the import, the language service takes you to the .d.ts. As I understand it, the reasons for this behavior are:

  1. It was easier to implement since the language service is already finding the .d.ts and not the .js.
  2. Assuming you are writing code based on an API (which is more orthodox from a software engineering point of view than looking at the implementation, although I know that in the real world, developers often have questions that won't be answered by the API documentation), then the .d.ts is more likely to describe the API in human-readable format than the .js, which for real-world modules (especially those that have gone through some transpilation process) may be organized using any number of tricky code patterns as long as all the right elements end up defined when it is done loading.
Matt McCutchen
  • 28,856
  • 2
  • 68
  • 75