上期我们说到了TypeScript装饰器(decorators)和JavaScript装饰器编译出的代码不同，我们的组件库已经改成了TypeScript，但很多项目还在使用JavaScript，所以这里来说说怎么在我们JavaScript版的React项目中直接使用TypeScript的包，并用babel编译。

安装TypeScript

npm install typescript

书写配置文件

TypeScript使用tsconfig.json文件管理工程配置，例如你想包含哪些文件和进行哪些检查。 让我们先创建一个简单的工程配置文件：

{
    "compilerOptions": {
        "outDir": "./dist/",
        "sourceMap": true,
        "noImplicitAny": true,
        "strictNullChecks": false,
        "module": "commonjs",
        "target": "ESNext",
        "jsx": "react",
        "experimentalDecorators": true,
        "emitDecoratorMetadata": true,
        "moduleResolution": "node",
        "allowJs": true
    }
}

这里我们为TypeScript设置了一些东西:

读取所有可识别的src目录下的文件（通过include）。
接受JavaScript做为输入（通过allowJs）。
生成的所有文件放在dist目录下（通过outDir）。
...
你可以在这里了解更多关于tsconfig.json文件的说明。

修改webpack配置文件

修改工程根目录下的webpack.config.js文件。

module.exports = {
    // ...
    resolve: {
        // Add '.ts' and '.tsx' as resolvable extensions.
        extensions: ['.js', '.ts', '.tsx']
    },

    module: {
        rules: [
            // All files with a '.ts' or '.tsx' extension will be handled by 'babel-loader'.
            {
                test: /\.tsx?$/,
                loader: 'babel-loader',
                options: {
                    presets: ['@babel/preset-typescript'],
                    plugins: [
                        ['@babel/plugin-transform-typescript', { allowNamespaces: true }],
                    ]
                },
            },
            {
                test: /\.jsx?$/,
                loader: 'babel-loader',
            },
        ]
    }
};

这里我们使用@babel/plugin-transform-typescript插件来处理TypeScript。

那么，TypeScript的类型检测怎么办呢？不是相当于废了吗？这里我们使用 fork-ts-checker-webpack-plugin来启用TypeScript类型检测。

配置TypeScript类型检查器

Install

npm install fork-ts-checker-webpack-plugin fork-ts-checker-notifier-webpack-plugin

webpack.config.js

const ForkTsCheckerWebpackPlugin = require('fork-ts-checker-webpack-plugin');
const ForkTsCheckerNotifierWebpackPlugin = require('fork-ts-checker-notifier-webpack-plugin');

module.exports = {
    // ...
    plugins: [
        new ForkTsCheckerWebpackPlugin({
            // 将async设为false，可以阻止Webpack的emit以等待类型检查器/linter，并向Webpack的编译添加错误。
            async: false
        }),
        // 将TypeScript类型检查错误以弹框提示
        // 如果fork-ts-checker-webpack-plugin的async为false时可以不用
        // 否则建议使用，以方便发现错误
        new ForkTsCheckerNotifierWebpackPlugin({
            title: 'TypeScript',
            excludeWarnings: true,
            skipSuccessful: true,
        }),
    ]
};

准备工作完成。
终于能试试期待已久的TypeScript了，心情好happy 😜
但是，等等，What？为什么报错了？

TS2304: Cannot find name 'If'.
TS2304: Cannot find name 'Choose'.
TS2304: Cannot find name 'When'.

原来是我们在React项目中使用了jsx-control-statements导致的。
怎么办？在线等，挺急的... 😜
我们发现，这里我们可以用tsx-control-statements来代替。

配置 tsx-control-statements

安装

npm install tsx-control-statements

在tsconfig.json文件的files选项中添加

{
    "compilerOptions": {
        "outDir": "./dist/",
        "sourceMap": true,
        "noImplicitAny": true,
        "strictNullChecks": false,
        "module": "commonjs",
        "target": "ESNext",
        "jsx": "react",
        "experimentalDecorators": true,
        "emitDecoratorMetadata": true,
        "moduleResolution": "node",
        "allowJs": true
    },
    "files": [
        "./node_modules/tsx-control-statements/index.d.tsx"
    ]
}

接下来我们按照TypeScript官网指南来把我们的代码改成TypeScript就可以了，这里就不作详细介绍了。

更便利的与ECMAScript模块的互通性

但是这就结束了么，no no no...
在编译过程中，我们发现有些包的导入有问题
比如，将i18next作为外部资源引用时（webpack的externals可以帮助我们实现该方式），我们发现代码被编译成

i18next_1['default'].t

但是i18next_1['default']的值是undefined，执行出错
为什么？哪里又双叒叕...有问题了？😭

ECMAScript模块在ES2015里才被标准化，在这之前，JavaScript生态系统里存在几种不同的模块格式，它们工作方式各有不同。 当新的标准通过后，社区遇到了一个难题，就是如何在已有的“老式”模块模式之间保证最佳的互通性。

TypeScript与Babel采取了不同的方案，并且直到现在，还没出现真正地固定标准。
在之前的版本，TypeScript 对 CommonJs/AMD/UMD 模块的处理方式与 ES6 模块不同，这会导致一些问题：

• 当导入一个 CommonJs/AMD/UMD 模块时，TypeScript 视 import * as koa from 'koa' 与 const koa = require('koa') 等价，但使用 import * as 创建的模块对象实际上不可被调用以及被实例化。
• 类似的，当导入一个 CommonJs/AMD/UMD 模块时，TypeScript 视 import koa from 'koa' 与 const koa = require('koa').default 等价，但在大部分 CommonJs/AMD/UMD 模块里，它们并没有默认导出。

在 2.7 后的版本里，TypeScript提供了一个新的 esModuleInterop标记，旨在解决上述问题。
当使用这个新的esModuleInterop标记时，可调用的CommonJS模块必须被做为默认导入：

import express from "express";

let app = express();

我们将其加入tsconfig.json文件中

{
    "compilerOptions": {
        "outDir": "./dist/",
        "sourceMap": true,
        "noImplicitAny": true,
        "strictNullChecks": false,
        "module": "commonjs",
        "target": "ESNext",
        "jsx": "react",
        "experimentalDecorators": true,
        "emitDecoratorMetadata": true,
        "allowSyntheticDefaultImports": true, // 允许使用 ES2015 默认的 import 风格
        "esModuleInterop": true, // 可调用的CommonJS模块必须被做为默认导入，在已有的“老式”模块模式之间保证最佳的互通性
        "moduleResolution": "node",
        "allowJs": true
    },
    "files": [
        "./node_modules/tsx-control-statements/index.d.tsx"
    ]
}

到了这里，我们的程序终于能完美的运行起来了。
我们不想再区分哪些需要使用import * as，哪些使用import，因此我们将格式统一为

import XX from 'XX'