TypeScript : module resolution

error TS2307: Cannot find module 'vue'.

原因：Module Resolution 设置错误
处理方式：

"compilerOptions": {
    ...
    "target": "esnext",  
    "moduleResolution": "node",  //增加此处配置
    }

}

找到模块后 declaration 使用不了的情况，需要自行增加 XXX.d.ts
export * from "redux"
export as namespace Redux

把声明的接口通过命名空间Redux暴露出来

以下参考自官方：

Module Resolution Strategies

There are two possible module resolution strategies: Node and Classic. You can use the --moduleResolution flag to specify the module resolution strategy. If not specified, the default is Classic for --module AMD | System | ES2015 or Node otherwise.

Classic

This used to be TypeScript’s default resolution strategy. Nowadays, this strategy is mainly present for backward compatibility.

A relative import will be resolved relative to the importing file. So import { b } from "./moduleB" in source file /root/src/folder/A.ts would result in the following lookups:

1./root/src/folder/moduleB.ts
2./root/src/folder/moduleB.d.ts

For non-relative module imports, however, the compiler walks up the directory tree starting with the directory containing the importing file, trying to locate a matching definition file.
For example:

A non-relative import to moduleB such as import { b } from "moduleB", in a source file /root/src/folder/A.ts, would result in attempting the following locations for locating "moduleB":

1./root/src/folder/moduleB.ts
2./root/src/folder/moduleB.d.ts
3./root/src/moduleB.ts
4./root/src/moduleB.d.ts
5./root/moduleB.ts
6./root/moduleB.d.ts
7./moduleB.ts
8./moduleB.d.ts

注意 这里不去查找node_modules内的定义

Node

This resolution strategy attempts to mimic the Node.js module resolution mechanism at runtime. The full Node.js resolution algorithm is outlined in Node.js module documentation.

TypeScript will mimic the Node.js run-time resolution strategy in order to locate definition files for modules at compile-time. To accomplish this, TypeScript overlays the TypeScript source file extensions (.ts, .tsx, and .d.ts) over the Node’s resolution logic. TypeScript will also use a field in package.json named "types" to mirror the purpose of "main" - the compiler will use it to find the “main” definition file to consult.

For example, an import statement like import { b } from "./moduleB" in /root/src/moduleA.ts would result in attempting the following locations for locating "./moduleB":

1./root/src/moduleB.ts
2./root/src/moduleB.tsx
3./root/src/moduleB.d.ts
4./root/src/moduleB/package.json (if it specifies a "types" property)
5./root/src/moduleB/index.ts
6./root/src/moduleB/index.tsx
7./root/src/moduleB/index.d.ts

Recall that Node.js looked for a file named moduleB.js, then an applicable package.json, and then for an index.js.

Similarly a non-relative import will follow the Node.js resolution logic, first looking up a file, then looking up an applicable folder. So import { b } from "moduleB" in source file /root/src/moduleA.ts would result in the following lookups:

1./root/src/node_modules/moduleB.ts
2./root/src/node_modules/moduleB.tsx
3./root/src/node_modules/moduleB.d.ts
4./root/src/node_modules/moduleB/package.json (if it specifies a "types" property)
5./root/src/node_modules/moduleB/index.ts
6./root/src/node_modules/moduleB/index.tsx
7./root/src/node_modules/moduleB/index.d.ts 

8./root/node_modules/moduleB.ts
9./root/node_modules/moduleB.tsx
10./root/node_modules/moduleB.d.ts
11./root/node_modules/moduleB/package.json (if it specifies a "types" property)
12./root/node_modules/moduleB/index.ts
13./root/node_modules/moduleB/index.tsx
14./root/node_modules/moduleB/index.d.ts 

15./node_modules/moduleB.ts
16./node_modules/moduleB.tsx
17./node_modules/moduleB.d.ts
18./node_modules/moduleB/package.json (if it specifies a "types" property)
19./node_modules/moduleB/index.ts
20./node_modules/moduleB/index.tsx
21./node_modules/moduleB/index.d.ts