上期我们说到了 TypeScript 装饰器 (decorators) 和 JavaScript 装饰器编译出的代码不同, 虽然我们的库是用 TypeScript 写的, 但很多时候需要提供给 JavaScript 使用, 所以这里来说说怎么将项目迁移至 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
- },
- "include": [
- "./src/**/*"
- ]
- }
这里我们为 TypeScript 设置了一些东西:
读取所有可识别的 src 目录下的文件(通过 include).
接受 JavaScript 做为输入(通过 allowJs).
生成的所有文件放在 dist 目录下(通过 outDir).
...
你可以在这里了解更多关于 tsconfig.JSON 文件的说明.
创建一个 webpack 配置文件
在工程根目录下创建一个 webpack.config.JS 文件.
- module.exports = {
- context: __dirname,
- entry: './src/index.tsx',
- output: {
- filename: 'bundle.js',
- path: `${__dirname}/dist`
- },
- // Enable sourcemaps for debugging webpack's output.
- devtool: "#source-map",
- 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'
- },
- ]
- }
- };
修改 babel 配置文件
安装需要的包
NPM install @babel/preset-typescript @babel/plugin-transform-typescript
将上面安装的包加入工程目录下的 babel.config.JS 文件.
- module.exports = {
- presets: ["@babel/preset-typescript", '@babel/preset-react', '@babel/preset-env', 'mobx'],
- plugins: [
- ['@babel/plugin-transform-typescript', { allowNamespaces: true }],
- // ... other
- ]
- }
这里我们使用 @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'
来源: http://www.jianshu.com/p/ad5831aca286