jiek 1.0.2 → 1.0.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +94 -4
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -1,12 +1,42 @@
|
|
|
1
1
|
# Jiek
|
|
2
2
|
|
|
3
|
-
为什么没有一个在 monorepo 下面足够现代又足够简单的构建工具呢？恭喜你发现了宝藏～
|
|
3
|
+
为什么没有一个在 `monorepo` 下面足够现代又足够简单的构建工具呢？恭喜你发现了宝藏～
|
|
4
|
+
|
|
5
|
+
## 为什么不使用 X？
|
|
6
|
+
|
|
7
|
+
- Q: [`tsup`](https://github.com/egoist/tsup)
|
|
8
|
+
- A: `tsup` 基于 esbuild 与 rollup，是他们上层的一个 no-config 构建工具
|
|
9
|
+
- 关于类型编译的支持并不足够智能，无法自动找到对应的 `tsconfig.json`，在 `monorepo` 下面会遇到相关的问题
|
|
10
|
+
- 虽然它是声称 no-config，但是在多入口，以及其他的复杂情况下的产物时，仍需要编写相关配置
|
|
11
|
+
- 偏向于使用 cli 中的相关参数，以及配置文件，不够自然
|
|
12
|
+
- 在 `monorepo` 的场景下使用起来进行开发时，在复杂依赖关系的情况下需要管理复杂的构建依赖关系
|
|
13
|
+
- 老牌工具，符合时代背景下的相关需求；沉淀时间久，功能相对来说较为完善；生态较为丰富，网络上的资源较多
|
|
14
|
+
|
|
15
|
+
- Q: [`unbuild`](https://github.com/unjs/unbuild)
|
|
16
|
+
- A: 该工具的底座技术与 `tsup` 也是极为一致，与其不同的便是他的 config 实际上是可以基于 package.json 生成的。
|
|
17
|
+
- 该工具与 `tsup` 一样，存在对：「`monorepo` 支持不好」、「不支持 Project Reference」这些问题
|
|
18
|
+
- 使用的时候你需要根据模版声明输出，再反向根据约定好的规则去创建相关的入口文件，不够自然，也不够灵活过于死板
|
|
19
|
+
- 不过该工具在无配置化上也前进了较大一步，对于一些简单的项目来说，是一个不错的选择
|
|
20
|
+
|
|
21
|
+
- Q: [`bunchee`](https://github.com/huozhi/bunchee)
|
|
22
|
+
- A: 换成了 `swc` + `rollup`，嗯。
|
|
23
|
+
- 同样在 `monorepo` 下有着相关问题，同样没办法处理 Project Reference
|
|
24
|
+
- 定义了一定的 exports 产物到输入文件的规则，能实现一定的灵活性，但是编写导出规则时会过于冗长
|
|
25
|
+
- 没办法在 monorepo 的复杂依赖关系场景中去减轻开发负担
|
|
26
|
+
|
|
27
|
+
## 安装
|
|
28
|
+
|
|
29
|
+
目前只支持 pnpm，因为 workspace 的相关机制在 pnpm 的支持是最好的（主要也没时间支持别的工具了）。
|
|
30
|
+
|
|
31
|
+
```bash
|
|
32
|
+
pnpm install -D jiek
|
|
33
|
+
```
|
|
4
34
|
|
|
5
35
|
## Features
|
|
6
36
|
|
|
7
37
|
### build
|
|
8
38
|
|
|
9
|
-
|
|
39
|
+
写构建脚本一直不是一件简单的事情，那么怎么把一个复杂的事情变简单呢？我们可以回到需求的本身，那就是「定义什么便构建什么」。在这里我们用自然的方式来定义构建产物，而不需要去多写一行多余的代码。
|
|
10
40
|
|
|
11
41
|
> 在这里你需要了解足够先进和现代的「[模块管理]()」以及「[导出策略]()」，在这里我们便是基于这俩点达成的一些自然而然的约定来实现的减轻负担。
|
|
12
42
|
|
|
@@ -14,13 +44,73 @@
|
|
|
14
44
|
|
|
15
45
|
#### 定义入口
|
|
16
46
|
|
|
47
|
+
在这里我们可以简单的对 exports 进行一定的扩展，在这里我们把我们定义在 `package.json` 中的 `exports` 字段可以看作为我们的入口文件。在这里我们简单定义一个入口：
|
|
48
|
+
|
|
49
|
+
```json
|
|
50
|
+
{
|
|
51
|
+
"exports": "./src/index.ts"
|
|
52
|
+
}
|
|
53
|
+
```
|
|
54
|
+
|
|
55
|
+
是不是很简单呢？没感觉？那你得试试其他的工具了，如果你不了解其他的工具，在这里我示范一段其他的工具你需要定义的：
|
|
56
|
+
|
|
57
|
+
<details>
|
|
58
|
+
|
|
59
|
+
```json
|
|
60
|
+
{
|
|
61
|
+
"type": "module",
|
|
62
|
+
"exports": {
|
|
63
|
+
"import": {
|
|
64
|
+
"types": "./dist/es/index.d.mts",
|
|
65
|
+
"default": "./dist/es/index.mjs"
|
|
66
|
+
},
|
|
67
|
+
"require": {
|
|
68
|
+
"types": "./dist/cjs/index.d.ts",
|
|
69
|
+
"default": "./dist/cjs/index.js"
|
|
70
|
+
}
|
|
71
|
+
}
|
|
72
|
+
}
|
|
73
|
+
```
|
|
74
|
+
|
|
75
|
+
</details>
|
|
76
|
+
|
|
77
|
+
> 在这里你肯定想问如果你有复杂的导出呢？或者说多个入口呢？在[这里](../pkger/README.md)你可以看到我们的工具的生成规则。
|
|
78
|
+
|
|
17
79
|
#### 运行指令
|
|
18
80
|
|
|
81
|
+
假设你有一个 pakcages 下面的包叫 `@monorepo/utils` ，那么你可以这样运行：
|
|
82
|
+
|
|
83
|
+
```shell
|
|
84
|
+
jiek build -f utils
|
|
85
|
+
```
|
|
86
|
+
|
|
87
|
+
是不是很简单呢？在这里我们只需要告诉工具我们的包名就可以了，其他的事情我们都不需要关心。
|
|
88
|
+
|
|
19
89
|
#### 个性化需求
|
|
20
90
|
|
|
91
|
+
我知道，你肯定想定义一些自己的东西，你可以在你的根目录或者包的根目录下面创建一个 `jiek.config.ts` 文件：
|
|
92
|
+
|
|
93
|
+
```typescript
|
|
94
|
+
import { defineConfig } from 'jiek'
|
|
95
|
+
|
|
96
|
+
export default defineConfig({
|
|
97
|
+
build: {
|
|
98
|
+
output: 'lib'
|
|
99
|
+
}
|
|
100
|
+
})
|
|
101
|
+
```
|
|
102
|
+
|
|
21
103
|
#### 幕后的故事
|
|
22
104
|
|
|
23
105
|
一些关于本工具的设计思路和实现细节，不阅读也不会影响各位的使用，感兴趣的各位可以看看。
|
|
24
106
|
|
|
25
|
-
-
|
|
26
|
-
-
|
|
107
|
+
- 入口的约定：还没写好
|
|
108
|
+
- 插件的抉择：还没写好
|
|
109
|
+
|
|
110
|
+
#### 补充内容
|
|
111
|
+
|
|
112
|
+
- 关于样式
|
|
113
|
+
- 关于类型
|
|
114
|
+
- 关于 `monorepo`
|
|
115
|
+
|
|
116
|
+
### publish
|