jiek 1.1.12 → 2.0.0

package/README.md

@@ -1,131 +1,78 @@
 # Jiek
 
-为什么没有一个在 `monorepo` 下面足够现代又足够简单的构建工具呢？恭喜你发现了宝藏～
-
-## 为什么不使用 X？
-
-- Q: [`tsup`](https://github.com/egoist/tsup)
-- A: `tsup` 基于 esbuild 与 rollup，是他们上层的一个 no-config 构建工具
-  - 关于类型编译的支持并不足够智能，无法自动找到对应的 `tsconfig.json`，在 `monorepo` 下面会遇到相关的问题
-  - 虽然它是声称 no-config，但是在多入口，以及其他的复杂情况下的产物时，仍需要编写相关配置
-  - 偏向于使用 cli 中的相关参数，以及配置文件，不够自然
-  - 在 `monorepo` 的场景下使用起来进行开发时，在复杂依赖关系的情况下需要管理复杂的构建依赖关系
-  - 老牌工具，符合时代背景下的相关需求；沉淀时间久，功能相对来说较为完善；生态较为丰富，网络上的资源较多
-
-- Q: [`unbuild`](https://github.com/unjs/unbuild)
-- A: 该工具的底座技术与 `tsup` 也是极为一致，与其不同的便是他的 config 实际上是可以基于 package.json 生成的。
-  - 该工具与 `tsup` 一样，存在对：「`monorepo` 支持不好」、「不支持 Project Reference」这些问题
-  - 使用的时候你需要根据模版声明输出，再反向根据约定好的规则去创建相关的入口文件，不够自然，也不够灵活过于死板
-  - 不过该工具在无配置化上也前进了较大一步，对于一些简单的项目来说，是一个不错的选择
-
-- Q: [`bunchee`](https://github.com/huozhi/bunchee)
-- A: 换成了 `swc` + `rollup`，嗯。
-  - 同样在 `monorepo` 下有着相关问题，同样没办法处理 Project Reference
-  - 定义了一定的 exports 产物到输入文件的规则，能实现一定的灵活性，但是编写导出规则时会过于冗长
-  - 没办法在 monorepo 的复杂依赖关系场景中去减轻开发负担
+| zh-Hans
+| [en](https://github.com/NWYLZW/jiek/blob/master/packages/jiek/.about/en/README.md)
+
+[![npm version](https://img.shields.io/npm/v/jiek)](https://npmjs.com/package/jiek)
+[![npm downloads](https://img.shields.io/npm/dm/jiek)](https://npm.chart.dev/jiek)
+
+> 基于 `package.json` 元数据并适用于 `Monorepo` 的**轻便**工具库编译管理套件。
+
+- [x] 自动推断：基于 `package.json` 的相关字段自动推断出构建规则，减少配置文件的编写，更加轻便与符合标准
+  - `exports`：根据入口文件推断构建目标与类型
+  - `imports`：定义路径别名，并在构建的时候自动 bundle 进来
+  - `type: module`：根据选项智能决定输出文件后缀，不需要考虑 `cjs` 与 `esm` 的适配问题
+  - `dependencies`、`peerDependencies`、`optionalDependencies`：自动将符合规则的依赖标记为 `external`
+  - `devDependencies`：将标记为开发依赖的 bundle 进对应的最终产物之中
+- [ ] 构建工具：支持多种构建工具，无需纠结于用 swc 还是 esbuild 又或者是 tsc
+  - [x] `esbuild`
+  - [x] `swc`
+  - [ ] `typescript`
+- [x] 工作空间友好：支持在 pnpm 下的工作空间开发范式
+  - [ ] 支持更多的 PM
+  - [ ] 更好的工作空间任务流
+- [x] 类型定义文件：支持聚合生成类型定义文件
+- [x] 监听模式：适配 rollup 的监听模式
+- [x] 发布适配：支持同构生成 `package.json` 等相关字段
+  - [ ] 根据 `package.json` 中的路径自动替换 README.md 中的相对路径链接为对应的网络链接
+- [x] CommonJS：产物兼容正在使用 cjs 的用户
+- [ ] 插件化
+  - [ ] Dotenv：支持 dotenv 配置文件
+  - [ ] Replacer：支持替换文件内容
 
 ## 安装
 
-目前只支持 pnpm，因为 workspace 的相关机制在 pnpm 的支持是最好的（主要也没时间支持别的工具了）。
-
 ```bash
-pnpm install -D jiek
+npm i -D jiek
+# or
+pnpm i -D jiek
+# or
+yarn add -D jiek
 ```
 
-## Features
-
-有啥好用的？
-
-- 简化你的导出规则，不需要去写一些能够自动化生成的代码
-- 自然而然的对你的输入进行构建，按照统一的规则你可以几乎不用去写多余的配置
-- 在构建的时候不再依赖预构建目标的依赖或者是整体的全量构建，每一次构建只需要关注自己的目标
-- 预集成了一套完整的构建工具链，自动根据需求激活相关的插件进行工作
-
-### build
+## 快速起步
 
-写构建脚本一直不是一件简单的事情，那么怎么把一个复杂的事情变简单呢？我们可以回到需求的本身，那就是「定义什么便构建什么」。在这里我们用自然的方式来定义构建产物，而不需要去多写一行多余的代码。
-
-> 在这里你需要了解足够先进和现代的「[模块管理]()」以及「[导出策略]()」，在这里我们便是基于这俩点达成的一些自然而然的约定来实现的减轻负担。
-
-接下来我们可以一步步的来看看我们的构建工具是如何工作的。
-
-#### 定义入口
-
-在这里我们可以简单的对 exports 进行一定的扩展，在这里我们把我们定义在 `package.json` 中的 `exports` 字段可以看作为我们的入口文件。在这里我们简单定义一个入口：
-
-```json
-{
-  "exports": "./src/index.ts"
-}
-```
+通过一些简单的方式能又快又轻松的生成需要的产物。
 
-是不是很简单呢？没感觉？那你得试试其他的工具了，如果你不了解其他的工具，在这里我示范一段其他的工具你需要定义的：
+- 在 `package.json` 中添加入口文件，这里需要设置为原文件路径。
 
-<details>
+  你可以在 Node.js 文档中查看更多对于 [exports](https://nodejs.org/api/packages.html#exports) 的相关内容。
 
 ```json
 {
-  "type": "module",
-  "exports": {
-    "import": {
-      "types": "./dist/es/index.d.mts",
-      "default": "./dist/es/index.mjs"
-    },
-    "require": {
-      "types": "./dist/cjs/index.d.ts",
-      "default": "./dist/cjs/index.js"
-    }
-  }
+  ...
+  "exports": "./src/index.ts",
+  ...
 }
 ```
 
-</details>
-
-> 在这里你肯定想问如果你有复杂的导出呢？或者说多个入口呢？在[这里](../pkger/README.md)你可以看到我们的工具的生成规则。
-
-#### 运行指令
-
-假设你有一个 pakcages 下面的包叫 `@monorepo/utils` ，那么你可以这样运行：
-
-```shell
-jiek build -f utils
-```
-
-是不是很简单呢？在这里我们只需要告诉工具我们的包名就可以了，其他的事情我们都不需要关心。
+- 假设你在工作空间下有一个包名字为 `@monorepo/utils` ，那么你可以运行 `jb utils` 来构建这个包。
 
-#### 个性化需求
+- 当你完成了开发的相关步骤后，在发布阶段你可以使用 `jk -f utils publish` 来发布你的包，本工具会自动转化并填充 `package.json` 对应的字段。
 
-我知道，你肯定想定义一些自己的东西，你可以在你的根目录或者包的根目录下面创建一个 `jiek.config.ts` 文件：
+  你可以添加 `-p/--preview` 参数来预览待发布的 `package.json` 的内容。
 
-```typescript
-import { defineConfig } from 'jiek'
+## CLI
 
-export default defineConfig({
-  build: {
-    output: 'lib'
-  }
-})
+```text
+Usage: jk [options] [command]
 ```
 
-#### 幕后的故事
-
-一些关于本工具的设计思路和实现细节，不阅读也不会影响各位的使用，感兴趣的各位可以看看。
-
-- 入口的约定：还没写好
-- 插件的抉择：还没写好
-
-#### 补充内容
-
-- 关于样式
-- 关于类型
-- 关于 `monorepo`
-
-#### 接下来要做的
+## 为什么不使用 X？
 
-- [ ] 支持更多的 PM
-- [ ] 工作空间构建流
-- [ ] 依赖分析工具
-  - 本次构建哪些在 pacakge 中声明的依赖没用用到，可以移除（提供配置关闭该警告）
-  - 针对构建产物的依赖关系生成关系图（可配置颗粒度为文件或者导出方法）
+在这里与 `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)。但是他们都有着一些共同问题没有解决，比如说：
 
-### publish
+- `monorepo` 的支持存在一定的问题，在依赖工作空间其他的包时必须重新编译相关依赖
+- 编写入口文件的规则过于繁琐，不够自然
+- 无法处理 `tsconfig.json` 中的 `Project Reference` 相关问题
+- 根据`conditions`

package/bin/jiek-build.js

@@ -0,0 +1,16 @@
+#!/usr/bin/env node
+import { existsSync } from 'node:fs'
+import { createRequire } from 'node:module'
+import { dirname, resolve } from 'node:path'
+import process from 'node:process'
+
+process.env.JIEK_IS_ONLY_BUILD = 'true'
+
+const __dirname = dirname(import.meta.url.replace('file://', ''))
+if (existsSync(resolve(__dirname, '../.jiek-dev-tag'))) {
+  const require = createRequire(import.meta.url)
+  require('esbuild-register')
+  require('../src/cli-only-build.ts')
+} else {
+  import('jiek/cli-only-build')
+}