jiek 1.1.13 → 2.0.0

Sign up to get free protection for your applications and to get access to all the features.
package/README.md CHANGED
@@ -1,21 +1,34 @@
1
1
  # Jiek
2
2
 
3
- | zh-Hans | [en](./.about/en/README.md) |
3
+ | zh-Hans
4
+ | [en](https://github.com/NWYLZW/jiek/blob/master/packages/jiek/.about/en/README.md)
4
5
 
5
6
  [![npm version](https://img.shields.io/npm/v/jiek)](https://npmjs.com/package/jiek)
6
7
  [![npm downloads](https://img.shields.io/npm/dm/jiek)](https://npm.chart.dev/jiek)
7
8
 
8
9
  > 基于 `package.json` 元数据并适用于 `Monorepo` 的**轻便**工具库编译管理套件。
9
10
 
10
- - 自动推断:基于 `package.json` 的相关字段自动推断出构建规则
11
+ - [x] 自动推断:基于 `package.json` 的相关字段自动推断出构建规则,减少配置文件的编写,更加轻便与符合标准
11
12
  - `exports`:根据入口文件推断构建目标与类型
12
- - `type: module`:当开启时智能决定输出文件后缀,不需要考虑 `cjs` 与 `esm` 的适配问题
13
+ - `imports`:定义路径别名,并在构建的时候自动 bundle 进来
14
+ - `type: module`:根据选项智能决定输出文件后缀,不需要考虑 `cjs` 与 `esm` 的适配问题
13
15
  - `dependencies`、`peerDependencies`、`optionalDependencies`:自动将符合规则的依赖标记为 `external`
14
16
  - `devDependencies`:将标记为开发依赖的 bundle 进对应的最终产物之中
15
- - 工作空间友好:支持在 pnpm 下的工作空间
16
- - 类型定义文件:支持聚合生成类型定义文件
17
- - 监听模式:适配 rollup 的监听模式
18
- - 发布适配:支持同构生成 `package.json` 等相关字段
17
+ - [ ] 构建工具:支持多种构建工具,无需纠结于用 swc 还是 esbuild 又或者是 tsc
18
+ - [x] `esbuild`
19
+ - [x] `swc`
20
+ - [ ] `typescript`
21
+ - [x] 工作空间友好:支持在 pnpm 下的工作空间开发范式
22
+ - [ ] 支持更多的 PM
23
+ - [ ] 更好的工作空间任务流
24
+ - [x] 类型定义文件:支持聚合生成类型定义文件
25
+ - [x] 监听模式:适配 rollup 的监听模式
26
+ - [x] 发布适配:支持同构生成 `package.json` 等相关字段
27
+ - [ ] 根据 `package.json` 中的路径自动替换 README.md 中的相对路径链接为对应的网络链接
28
+ - [x] CommonJS:产物兼容正在使用 cjs 的用户
29
+ - [ ] 插件化
30
+ - [ ] Dotenv:支持 dotenv 配置文件
31
+ - [ ] Replacer:支持替换文件内容
19
32
 
20
33
  ## 安装
21
34
 
@@ -27,100 +40,37 @@ pnpm i -D jiek
27
40
  yarn add -D jiek
28
41
  ```
29
42
 
30
- ## 使用
43
+ ## 快速起步
31
44
 
32
- ### 构建
45
+ 通过一些简单的方式能又快又轻松的生成需要的产物。
33
46
 
34
- 写构建脚本一直不是一件简单的事情,那么怎么把一个复杂的事情变简单呢?我们可以回到需求的本身,那就是「定义什么便构建什么」。在这里我们用自然的方式来定义构建产物,而不需要去多写一行多余的代码。
47
+ - 在 `package.json` 中添加入口文件,这里需要设置为原文件路径。
35
48
 
36
- > 在这里你需要了解足够先进和现代的「[模块管理]()」以及「[导出策略]()」,在这里我们便是基于这俩点达成的一些自然而然的约定来实现的减轻负担。
37
-
38
- 接下来我们可以一步步的来看看我们的构建工具是如何工作的。
39
-
40
- #### 定义入口
41
-
42
- 在这里我们可以简单的对 exports 进行一定的扩展,在这里我们把我们定义在 `package.json` 中的 `exports` 字段可以看作为我们的入口文件。在这里我们简单定义一个入口:
43
-
44
- ```json
45
- {
46
- "exports": "./src/index.ts"
47
- }
48
- ```
49
-
50
- 是不是很简单呢?没感觉?那你得试试其他的工具了,如果你不了解其他的工具,在这里我示范一段其他的工具你需要定义的:
51
-
52
- <details>
49
+ 你可以在 Node.js 文档中查看更多对于 [exports](https://nodejs.org/api/packages.html#exports) 的相关内容。
53
50
 
54
51
  ```json
55
52
  {
56
- "type": "module",
57
- "exports": {
58
- "import": {
59
- "types": "./dist/es/index.d.mts",
60
- "default": "./dist/es/index.mjs"
61
- },
62
- "require": {
63
- "types": "./dist/cjs/index.d.ts",
64
- "default": "./dist/cjs/index.js"
65
- }
66
- }
53
+ ...
54
+ "exports": "./src/index.ts",
55
+ ...
67
56
  }
68
57
  ```
69
58
 
70
- </details>
71
-
72
- > 在这里你肯定想问如果你有复杂的导出呢?或者说多个入口呢?在[这里](../pkger/README.md)你可以看到我们的工具的生成规则。
73
-
74
- #### 运行指令
75
-
76
- 假设你有一个 pakcages 下面的包叫 `@monorepo/utils` ,那么你可以这样运行:
77
-
78
- ```shell
79
- jiek build -f utils
80
- ```
81
-
82
- 是不是很简单呢?在这里我们只需要告诉工具我们的包名就可以了,其他的事情我们都不需要关心。
59
+ - 假设你在工作空间下有一个包名字为 `@monorepo/utils` ,那么你可以运行 `jb utils` 来构建这个包。
83
60
 
84
- #### 个性化需求
61
+ - 当你完成了开发的相关步骤后,在发布阶段你可以使用 `jk -f utils publish` 来发布你的包,本工具会自动转化并填充 `package.json` 对应的字段。
85
62
 
86
- 我知道,你肯定想定义一些自己的东西,你可以在你的根目录或者包的根目录下面创建一个 `jiek.config.ts` 文件:
63
+ 你可以添加 `-p/--preview` 参数来预览待发布的 `package.json` 的内容。
87
64
 
88
- ```typescript
89
- import { defineConfig } from 'jiek'
65
+ ## CLI
90
66
 
91
- export default defineConfig({
92
- build: {
93
- output: 'lib'
94
- }
95
- })
67
+ ```text
68
+ Usage: jk [options] [command]
96
69
  ```
97
70
 
98
- #### 幕后的故事
99
-
100
- 一些关于本工具的设计思路和实现细节,不阅读也不会影响各位的使用,感兴趣的各位可以看看。
101
-
102
- - 入口的约定:还没写好
103
- - 插件的抉择:还没写好
104
-
105
- #### 补充内容
106
-
107
- - 关于样式
108
- - 关于类型
109
- - 关于 `monorepo`
110
-
111
- #### 接下来要做的
112
-
113
- - [ ] 支持更多的 PM
114
- - [ ] 工作空间构建流
115
- - [ ] 依赖分析工具
116
- - 本次构建哪些在 package 中声明的依赖没用用到,可以移除(提供配置关闭该警告)
117
- - 针对构建产物的依赖关系生成关系图(可配置颗粒度为文件或者导出方法)
118
-
119
- ### 发布
120
-
121
71
  ## 为什么不使用 X?
122
72
 
123
- 在这里与 `jiek` 类似的工具有:[`tsup`](https://github.com/egoist/tsup)、[`unbuild`](https://github.com/unjs/unbuild)、[`bunchee`](https://github.com/huozhi/bunchee)、[`pkgroll`](https://github.com/privatenumber/pkgroll)、[`tsdown`](https://github.com/sxzz/tsdown)。但是他们都有着一些共同问题没有解决,我们来看看:
73
+ 在这里与 `jiek` 类似的工具有:[tsup](https://github.com/egoist/tsup)、[unbuild](https://github.com/unjs/unbuild)、[bunchee](https://github.com/huozhi/bunchee)、[pkgroll](https://github.com/privatenumber/pkgroll)、[tsdown](https://github.com/sxzz/tsdown)。但是他们都有着一些共同问题没有解决,比如说:
124
74
 
125
75
  - `monorepo` 的支持存在一定的问题,在依赖工作空间其他的包时必须重新编译相关依赖
126
76
  - 编写入口文件的规则过于繁琐,不够自然
@@ -0,0 +1,16 @@
1
+ #!/usr/bin/env node
2
+ import { existsSync } from 'node:fs'
3
+ import { createRequire } from 'node:module'
4
+ import { dirname, resolve } from 'node:path'
5
+ import process from 'node:process'
6
+
7
+ process.env.JIEK_IS_ONLY_BUILD = 'true'
8
+
9
+ const __dirname = dirname(import.meta.url.replace('file://', ''))
10
+ if (existsSync(resolve(__dirname, '../.jiek-dev-tag'))) {
11
+ const require = createRequire(import.meta.url)
12
+ require('esbuild-register')
13
+ require('../src/cli-only-build.ts')
14
+ } else {
15
+ import('jiek/cli-only-build')
16
+ }