2023-02-10 17:09:40 +08:00
|
|
|
|
# package.json
|
|
|
|
|
|
|
|
|
|
## ~ ^ version
|
|
|
|
|
|
|
|
|
|
- ~version: 近似等于的版本,会将您更新到所有未来的补丁版本,而不会增加次要版本。 ~1.2.3 将使用从 1.2.3 到 <1.3.0 的版本。
|
|
|
|
|
|
|
|
|
|
- ^version: 兼容版本,将更新到所有未来的次要/补丁版本,而不增加主要版本。 ^2.3.4 将使用从 2.3.4 到 <3.0.0 的版本。
|
|
|
|
|
|
|
|
|
|
## typings / types
|
|
|
|
|
|
|
|
|
|
tsc 编译后,根据`tsconfig.json`的`outDir`属性,定位入口文件`src/index.ts`的编译后的输出位置
|
|
|
|
|
|
|
|
|
|
e.g
|
|
|
|
|
|
|
|
|
|
```json
|
|
|
|
|
// tsconfig.build.json
|
|
|
|
|
{
|
|
|
|
|
"compilerOptions": {
|
|
|
|
|
"outDir": "dist",
|
|
|
|
|
"declaration": true // tsc编译生成.d.ts
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
默认编译完成后。`src/index.ts`编译到`dist/index.js`
|
|
|
|
|
|
|
|
|
|
```json
|
|
|
|
|
// package.json
|
|
|
|
|
{
|
|
|
|
|
"main": "dist/index.js",
|
|
|
|
|
"types": "dist/index.d.ts"
|
|
|
|
|
}
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
这种情况,作为依赖,`workspace`下的其他包引入,`vscode`会有代码提示
|
|
|
|
|
|
2023-02-24 18:00:48 +08:00
|
|
|
|
## 入口文件
|
|
|
|
|
|
|
|
|
|
- 如果 npm 包导出的是 ESM 规范的包,使用 module
|
|
|
|
|
- 如果 npm 包只在 web 端使用,并且严禁在 server 端使用,使用 browser。
|
|
|
|
|
- 如果 npm 包只在 server 端使用,使用 main
|
|
|
|
|
- 如果 npm 包在 web 端和 server 端都允许使用,使用 browser 和 main
|
|
|
|
|
- 其他更加复杂的情况,如 npm 包需要提供 commonJS 与 ESM 等多个规范的代码文件,请参考上述使用场景或流程图
|
|
|
|
|
|
2023-02-10 17:09:40 +08:00
|
|
|
|
# tsconfig.json
|
|
|
|
|
|
|
|
|
|
指定了用来编译这个项目的根文件和编译选项
|
|
|
|
|
|
|
|
|
|
## tsc 命令
|
|
|
|
|
|
|
|
|
|
tsconfig.json 将文件夹转变一个“工程” 如果不指定任何 “exclude”或“files”,文件夹里的所有文件包括 tsconfig.json 和所有的子目录都会在编译列表里。 如果你想利用 “exclude”排除某些文件,甚至你想指定所有要编译的文件列表,请使用“files”。
|
|
|
|
|
|
|
|
|
|
- 不带 tsconfig.json: 默认读当前目录 tsconfig.json
|
|
|
|
|
- 带 tsconfig.json: 参数 -p /path/tsconfing.json
|
|
|
|
|
|
|
|
|
|
## include && exclude
|
|
|
|
|
|
|
|
|
|
> 使用 "outDir"指定的目录下的文件永远会被编译器排除,除非你明确地使用"files"将其包含进来(这时就算用 exclude 指定也没用)。
|
|
|
|
|
|
|
|
|
|
`include`包含的文件使用`exclude`排斥
|
|
|
|
|
|
|
|
|
|
`exclude`认情况下会排除
|
|
|
|
|
|
|
|
|
|
- node_modules
|
|
|
|
|
- bower_components
|
|
|
|
|
- jspm_packages
|
|
|
|
|
- <outDir>目录
|
|
|
|
|
`
|
|
|
|
|
|
|
|
|
|
## baseUrl && paths
|
|
|
|
|
|
|
|
|
|
> https://www.tslang.cn/docs/handbook/module-resolution.html#base-url
|
|
|
|
|
|
|
|
|
|
解析非相对模块名的基准目录。查看 `模块解析` 文档了解详情。
|
|
|
|
|
|
|
|
|
|
相对于 `tsconfig.json` 当前所在的路径
|
|
|
|
|
|
|
|
|
|
> 相对模块的导入不会被设置的 baseUrl 所影响
|
|
|
|
|
|
|
|
|
|
tsconfig.json 中通过 baseUrl 和 paths 指定,主要用于 ts 编译,VSCode 编辑器也会据此对路径进行检查和补全
|
|
|
|
|
|
|
|
|
|
paths 只影响 tsc 编译,但不会对输出内容进行修改。也就是说,ts-loader(或 babel-loader)输出的 js 文件还会是基于相对路径引入的。如果 webpack 不配置对应的 alias,后续构建将会出错。
|
|
|
|
|
|
|
|
|
|
如果 tsconfig 中 allowJS 为 true,VSCode 也会对 js 代码中的相对路径进行解析,从而实现检查补全和跳转。
|
|
|
|
|
|
|
|
|
|
e.g.
|
|
|
|
|
|
|
|
|
|
```json
|
|
|
|
|
{
|
|
|
|
|
"compilerOptions": {
|
|
|
|
|
"baseUrl": ".", // 一般tsconfig.json在根目录。↓ node_modules同级
|
|
|
|
|
"paths": {
|
|
|
|
|
"jquery": ["node_modules/jquery/dist/jquery"] // 此处映射是相对于"baseUrl"
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
注意"paths"是相对于"baseUrl"进行解析。 如果 "baseUrl"被设置成了除"."外的其它值,比如 tsconfig.json 所在的目录,那么映射必须要做相应的改变。 如果你在上例中设置了 "baseUrl": "./src",那么 jquery 应该映射到"../node_modules/jquery/dist/jquery"。
|
|
|
|
|
|
|
|
|
|
## 跟踪模块解析
|
|
|
|
|
|
|
|
|
|
如之前讨论,编译器在解析模块时可能访问当前文件夹外的文件。 这会导致很难诊断模块为什么没有被解析,或解析到了错误的位置。 通过 --traceResolution 启用编译器的模块解析跟踪,它会告诉我们在模块解析过程中发生了什么。
|
|
|
|
|
|
|
|
|
|
假设我们有一个使用了 typescript 模块的简单应用。 app.ts 里有一个这样的导入`import * as ts from "typescript"`。
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
│ tsconfig.json
|
|
|
|
|
├───node_modules
|
|
|
|
|
│ └───typescript
|
|
|
|
|
│ └───lib
|
|
|
|
|
│ typescript.d.ts
|
|
|
|
|
└───src
|
|
|
|
|
app.ts
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
使用--traceResolution 调用编译器。
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
tsc --traceResolution
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
## 参数表
|
|
|
|
|
|
|
|
|
|
[文档链接](https://www.tslang.cn/docs/handbook/compiler-options.html)
|
|
|
|
|
|
|
|
|
|
## 模块解析
|
|
|
|
|
|
|
|
|
|
[文档链接](https://www.tslang.cn/docs/handbook/module-resolution.html)
|
|
|
|
|
|
|
|
|
|
# tsc & webpack
|
|
|
|
|
|
|
|
|
|
typescritp 的 `tsc` 命令是非常稳妥的编译工具,负责把 ts 编译成 js
|
|
|
|
|
|
|
|
|
|
webpack 负责构建,根据 esmodule、commonjs 规范,找到对应的依赖,通过 babel-loader 的转译、降级成 node、browser 支持的 js 代码
|
|
|
|
|
|
|
|
|
|
esbuild 同 webpack 一样,速度更快,但是 production 稳定性待考究
|
|
|
|
|
|
2023-02-13 09:27:23 +08:00
|
|
|
|
## 移花接木 cjs(.js) + es(d.ts) 小操作
|
|
|
|
|
|
2023-02-13 09:41:08 +08:00
|
|
|
|
场景:monorepo 架构下,某些基础子包作为工具包,无需发布,例如 nestjs 外部依赖 `@demo/util`的某个方法,因为在`node`环境,如果用 `commonjs` 规范开发,再走 tsc 编译,生成的 `index.d.ts` IDE 无法进行代码智能提示。
|
2023-02-13 09:27:23 +08:00
|
|
|
|
|
|
|
|
|
- 利用 `tsc 构建`, `cjs` 和 `es` 规范的两个编译版本
|
|
|
|
|
- 在 `package.json` 入口默认使用 `cjs` 规范的 `js` 文件,同时,types 文件使用 `es` 规范的 `d.ts` 文件
|
|
|
|
|
|
|
|
|
|
```json
|
|
|
|
|
// tsconfig.build-cjs.json
|
|
|
|
|
{
|
|
|
|
|
"compilerOptions": {
|
|
|
|
|
"module": "CommonJS",
|
|
|
|
|
"outDir": "./dist/cjs"
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
//
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
再来个 esmodule 规范的
|
|
|
|
|
|
|
|
|
|
```json
|
|
|
|
|
// tsconfig.build-es.json
|
|
|
|
|
{
|
|
|
|
|
"compilerOptions": {
|
|
|
|
|
"outDir": "./dist/es"
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
骚操作来了
|
|
|
|
|
|
|
|
|
|
```json
|
|
|
|
|
// package.json
|
|
|
|
|
{
|
|
|
|
|
"name": "@demo/util",
|
|
|
|
|
"main": "dist/cjs/index",
|
|
|
|
|
"types": "dist/es/index.d.ts"
|
|
|
|
|
}
|
|
|
|
|
```
|
|
|
|
|
|
2023-02-10 17:46:17 +08:00
|
|
|
|
# 坑点
|
|
|
|
|
|
|
|
|
|
## vite 项目引包报错
|
|
|
|
|
|
|
|
|
|
能够直接读取 tsconfig.json 并使用同样的路径解析方式。用这个插件替换掉上面的 alias 配置就能保证路径解析规则在 vite 和 create-react-app 环境中保持一致。
|
|
|
|
|
|
|
|
|
|
```js
|
|
|
|
|
import tsconfigPaths from "vite-tsconfig-paths";
|
|
|
|
|
|
|
|
|
|
// https://vitejs.dev/config/
|
|
|
|
|
export default defineConfig({
|
|
|
|
|
plugins: [react(), tsconfigPaths()],
|
|
|
|
|
});
|
|
|
|
|
```
|
|
|
|
|
|
2023-02-10 17:09:40 +08:00
|
|
|
|
# 待解决的问题
|
|
|
|
|
|
2023-02-11 09:51:44 +08:00
|
|
|
|
## 自动化编译构建依赖?真的需要吗?
|
2023-02-10 17:09:40 +08:00
|
|
|
|
|
|
|
|
|
monorepo 下,开发阶段,本地的子包,实时的编译、构建,每次开发完子包,build 手动太麻烦了
|
|
|
|
|
|
|
|
|
|
- chokidar 监听 packages 下的全部文件夹
|
|
|
|
|
- 触发 ts 编译过程
|
|
|
|
|
|
|
|
|
|
## 子包独立发布到 npm
|
|
|
|
|
|
|
|
|
|
每个子包,作为基础物料,可以独立打包发布,也就说每个子包需要配置 Webpack 进行独立的打包
|