Chapter 13 #13
Chapter 13 #13
Conversation
|
|
||
| ## Understanding Modules and Scripts | ||
|
|
||
| TypeScript has two ways of understanding what a `.ts` file is. It can be treated either as a module, containing imports and exports, or a script, which executes in the global scope. |
There was a problem hiding this comment.
😉
| TypeScript has two ways of understanding what a `.ts` file is. It can be treated either as a module, containing imports and exports, or a script, which executes in the global scope. | |
| JavaScript has two ways of understanding what a `.js` file is. It can be treated either as a module, containing imports and exports, or a script, which executes in the global scope. |
There was a problem hiding this comment.
I know that you mentioned later that modules are available in JS and all - but a few paragraphs at the beginning here make it sound like it's a TS feature and maybe even that somehow it crept to JS or something. I feel like it's not emphasized enough that it's the other way around.
|
|
||
| ### Declaration Files Can Add To The Global Scope | ||
|
|
||
| Just like regular TypeScript files, declaration files can be treated as either modules or scripts based on whether or not the `export` keyword is used. In the example above, `musicPlayer.d.ts` is treated as a module because it includes the `export` keyword. |
There was a problem hiding this comment.
I'm honestly not sure if export is enough for declaration files to be treated as modules. But maybe it is and the effect I'm going to show is caused by something else...
Despite export being present in the declaration file you can still import just anything available identifier from it: TS playground. It doesn't feel very modele-y ;p
You can "fix" it by including export {} in the file: TS playground
|
|
||
| Just like regular TypeScript files, declaration files can be treated as either modules or scripts based on whether or not the `export` keyword is used. In the example above, `musicPlayer.d.ts` is treated as a module because it includes the `export` keyword. | ||
|
|
||
| This means that without an `export`, declaration files can be used to add types to the global scope. Even setting `moduleDetection` to `force` won't change this behavior - `moduleDetection` is always set to `auto` for `.d.ts` files. |
There was a problem hiding this comment.
The thing I mentioned above raises the question wheter this sentence is correct or not. But like I mentioned, I'm not exactly sure 🤷
|
|
||
| We don't need to put this in a declaration file. We can get exactly the same behavior by changing `express.d.ts` to `express.ts`. | ||
|
|
||
| This example is a little bit silly - there's no real use case for adding your own type to a module. But we'll see later that augmenting the types of modules can be extremely useful. |
There was a problem hiding this comment.
It can be nice to include some types that were not exported by that module. It's surely a somewhat confusing hack but gives u some meaning and colocation so I can see how people could like it.
| numbers.map((n) => n * 2); | ||
| ``` | ||
|
|
||
| Let's step back for a minute. How does TypeScript know that `.map` exists on an array? How does it know that `.map` exists, but `.transform` doesn't? Where is this defined |
There was a problem hiding this comment.
| Let's step back for a minute. How does TypeScript know that `.map` exists on an array? How does it know that `.map` exists, but `.transform` doesn't? Where is this defined | |
| Let's step back for a minute. How does TypeScript know that `.map` exists on an array? How does it know that `.map` exists, but `.transform` doesn't? Where is this defined? |
|
|
||
| Looking at the code in `node_modules/typescript/lib`, you'll see dozens of declaration files that describe the JavaScript environment. | ||
|
|
||
| Understanding how to navigate these declaration files can be very useful for fixing type errors. Take a few minutes to explore what's in `lib.es5.d.ts` by using 'go to definition' to navigate around. |
There was a problem hiding this comment.
For funsies... one could swap out all lib files and use a custom module describing even how an Array interface should look like and more. There are options to do that :D I'd really expect that there would be dragons if you'd do that for some very core functionality though. Although internally, TS always tries to load those definitions from the used lib files.
|
|
||
| This means that if you make a mistake authoring a declaration file, TypeScript won't catch it. This can lead to bugs that are difficult to track down. | ||
|
|
||
| This is one of my main gripes with TypeScript - `skipLibCheck` is a must-have, because of the danger of incorrect third-party declaration files. But it also makes authoring your own declaration files much harder. |
There was a problem hiding this comment.
Playing devil's advocate - if your 3rd party declaration file has an error and you suppress it... how do you know that it won't affect u in some under-specified way? You are effectively rolling a die at this point to see when and how it might affect you.
No description provided.