From 877e9c6c5e3de29f921b81dc31df5b1d96da6185 Mon Sep 17 00:00:00 2001 From: Daniel Rosenwasser Date: Sun, 13 Mar 2016 20:58:01 -0700 Subject: [PATCH 1/3] Fix-ups prior to "Module Resolution Strategies --- pages/Module Resolution.md | 50 ++++++++++++++++++++------------------ 1 file changed, 27 insertions(+), 23 deletions(-) diff --git a/pages/Module Resolution.md b/pages/Module Resolution.md index ea7aa3e1a..805edf677 100644 --- a/pages/Module Resolution.md +++ b/pages/Module Resolution.md @@ -1,42 +1,46 @@ > This section assumes some basic knowledge about modules. Please see the [Modules](./Modules.md) documentation for more information. -"Module Resolution" refers to the process the compiler follows to understand the shape of an import target. -Consider an import statement like `import { a } from "./moduleA"`; to be able to correctly check any use of the import target `a`, the compiler needs to know what it means, and what is its type. -To do that, the compiler needs to inspect the exported declaration with name `a` from `moduleA`. -This could be defined in a `.ts` file from your own code, or in a `.d.ts` for an external definition file that your code depends on. -The first step, is to locate the definition of `moduleA`. +*Module resolution* is the process the compiler takes to figure out exactly what an import refers to. +Consider an import statement like `import { a } from "moduleA"`; +in order to check any use of `a`, the compiler needs to know exactly what it represents, and will need to check its definition `moduleA`. -The process to locate a module goes as follows: +At this point, the compiler will ask itself "what's the shape of `moduleA`?" +While this sounds straightforward, `moduleA` could be defined in one of your own a `.ts`/`.tsx` files, or in a `.d.ts` that your code depends on. -* Locate a file with the module definition +First, the compiler will try to locate a file that represents the imported module. +To do so the compiler follows one of two different strategies: [Classic](#classic) or [Node](#node). +These strategies tell the compiler *where* to look for `moduleA`. - The compiler will try to first locate a file containing the definition of the imported module. - To do so the compiler follows one of two different strategies: [Classic](#classic) and [Node](#node). +If that didn't work and if the module name is non-relative (and in the case of `"moduleA`, it is), then the compiler will attempt to locate an [ambient module declaration](#ambient-module-declarations). +We'll cover non-relative imports next. -* Locate an ambient module declaration - - If no file was found, the compiler will attempt to locate an [ambient module declaration](#ambient-module-declaration) for the module if applicable. - -* Log an error if all failed - - If none were found, you will get `error TS2307: Cannot find module 'moduleA'.` +Finally, if the compiler could not resolve the module, it will log an error. +In this case, the error would be something like `error TS2307: Cannot find module 'moduleA'.` ## Relative vs. Non-relative module imports Module imports are resolved differently based on whether the module reference is relative or non-relative. -A **relative** import is one that stars with `/`, `./` or `../`. +A *relative import* is one that stars with `/`, `./` or `../`. +Some examples include: + + * `import Entry from "./components/Entry";` + * `import { DefaultHeaders } from "../constants/http";` + * `import "/mod";` + +Any other import is considered **non-relative**. +Some examples include: -A **non-relative** import is one that does *not* start with either. + * `import * as $ from "jQuery"; + * `import { Component } from "angular2/core";` -A relative import is resolved relative to the importing file. -A relative import can **not** resolve to an ambient module declaration. -Use this for importing your own modules that are guaranteed to maintain their relative location at runtime. +A relative import is resolved relative to the importing file and *cannot* resolve to an ambient module declaration. +You should use relative imports for your own modules that are guaranteed to maintain their relative location at runtime. -A non-relative import can be resolved relative to `baseUrl`, or through path mapping. +A non-relative import can be resolved relative to `baseUrl`, or through path mapping, which we'll cover below. They can also resolve to ambient module declarations. -Use non-relative imports to import external module dependencies. +Use non-relative paths when importing any of your external dependnecies. ## Module Resolution Strategies From c202b903a479ed931b272dade90aff58edeaf5ce Mon Sep 17 00:00:00 2001 From: Daniel Rosenwasser Date: Mon, 14 Mar 2016 23:52:33 -0700 Subject: [PATCH 2/3] Update Module Resolution.md --- pages/Module Resolution.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/pages/Module Resolution.md b/pages/Module Resolution.md index 805edf677..7e4f4bf6a 100644 --- a/pages/Module Resolution.md +++ b/pages/Module Resolution.md @@ -1,12 +1,12 @@ > This section assumes some basic knowledge about modules. Please see the [Modules](./Modules.md) documentation for more information. -*Module resolution* is the process the compiler takes to figure out exactly what an import refers to. +*Module resolution* is the process the compiler uses to figure out what an import refers to. Consider an import statement like `import { a } from "moduleA"`; in order to check any use of `a`, the compiler needs to know exactly what it represents, and will need to check its definition `moduleA`. -At this point, the compiler will ask itself "what's the shape of `moduleA`?" -While this sounds straightforward, `moduleA` could be defined in one of your own a `.ts`/`.tsx` files, or in a `.d.ts` that your code depends on. +At this point, the compiler will ask "what's the shape of `moduleA`?" +While this sounds straightforward, `moduleA` could be defined in one of your own `.ts`/`.tsx` files, or in a `.d.ts` that your code depends on. First, the compiler will try to locate a file that represents the imported module. To do so the compiler follows one of two different strategies: [Classic](#classic) or [Node](#node). @@ -22,7 +22,7 @@ In this case, the error would be something like `error TS2307: Cannot find modul Module imports are resolved differently based on whether the module reference is relative or non-relative. -A *relative import* is one that stars with `/`, `./` or `../`. +A *relative import* is one that starts with `/`, `./` or `../`. Some examples include: * `import Entry from "./components/Entry";` From fc0c9398b7dcb34dd3cef55501754f90a350aa4d Mon Sep 17 00:00:00 2001 From: Daniel Rosenwasser Date: Mon, 14 Mar 2016 23:53:25 -0700 Subject: [PATCH 3/3] Update Module Resolution.md --- pages/Module Resolution.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/Module Resolution.md b/pages/Module Resolution.md index 7e4f4bf6a..d069f3ac8 100644 --- a/pages/Module Resolution.md +++ b/pages/Module Resolution.md @@ -12,7 +12,7 @@ First, the compiler will try to locate a file that represents the imported modul To do so the compiler follows one of two different strategies: [Classic](#classic) or [Node](#node). These strategies tell the compiler *where* to look for `moduleA`. -If that didn't work and if the module name is non-relative (and in the case of `"moduleA`, it is), then the compiler will attempt to locate an [ambient module declaration](#ambient-module-declarations). +If that didn't work and if the module name is non-relative (and in the case of `"moduleA"`, it is), then the compiler will attempt to locate an [ambient module declaration](#ambient-module-declarations). We'll cover non-relative imports next. Finally, if the compiler could not resolve the module, it will log an error.