艺述论

Appearance

🔰 bun 介绍三：dotenv 与 nodemon 都不再需要了

🕒 Published at:

bun 介绍三：dotenv 与 nodemon 都不再需要了 ​

上一篇主要介绍了 bun 的启动模式及如何使用 jsx 语法。我在上一篇的朋友圈评论区说过，bun 与 Node.js 之争，最终可能就是内存与 CPU 之争；bun 能否推广起来，就看单用户成本中的 CPU 成本与内存成本哪个更贵。

这个是可以测算的，对于使用云主机的团队，很容易就能计算出来哪个单位用户的成本更高。在开始测算的时候，可以采用 A/B 版本策略，A 版本使用 Node.js，B 版本使用 bun。在部署的时候，安装 bun 的机器可以把内存分配得高一些，依据昨天我的初步测试数据，B 版本的大内存主机，它的内存至少要比以往 Node.js 版本的主机大 4 倍以上。

应用跑起来了，然后进行测试，对比 A、B 版本的单用户服务消耗的主机成本。一个很有可能的结果是，大概率内存更廉价，使用 bun 将大大节约成本，尤其在有海量用户、需求高频且交互频繁的应用上，成本节约会很明显，例如美团、饿了吗等。

在云主机成本降低的同时，由于响应时间变少了，开发效率提升了，在用户体验和团队开发体验方便也会有适量改善。

这一篇我们继续研究与学习 bun。

1、对 text、json、toml 文件的直接支持 ​

所谓直接支持，就是在代码中可以使用这些文件，对text等这三类文件都有很好的加载支持：

js
// src/index.ts
// text
console.log("text", require("./text.txt").default);
import text from "./text.txt"
console.log("text", text); // 输出文本

// json
import json from "./json.json"
console.log("json", json); // 输出json

// toml
import toml from "./toml.toml"
console.log("toml", toml); // 输出json
// src/index.ts
// text
console.log("text", require("./text.txt").default);
import text from "./text.txt"
console.log("text", text); // 输出文本

// json
import json from "./json.json"
console.log("json", json); // 输出json

// toml
import toml from "./toml.toml"
console.log("toml", toml); // 输出json

并且，前面提到过，bun 对这些文件的支持不需要额外的加载器；换句话讲，bun 把对常用文件类型的加载、解析等功能，都内置在它自己的体内了。

唯一需要注意的是，bun 对 toml 文件的解析结果，仍然是 json 格式。这是为了方便数据操作。

2、对 wasm 的支持 ​

bun 支持的 wasm 文件，是一种遵守 wasip1 规范的一种跨语言中间包，它由其它高级语言，譬如 Golang、Rust、C 等编写，编译成为.wasm 文件，然后在 js 中使用，目的是为了提升代码执行的性能。目前 bun 对 wasm 的支持还不是很完善。

js
// wasm
import wasm from "./bun.wasm";
console.log("wasm", wasm); // .../src/bun.wasm
// bun run bun.wasm // hello world
// wasm
import wasm from "./bun.wasm";
console.log("wasm", wasm); // .../src/bun.wasm
// bun run bun.wasm // hello world

我大致试了一下，第 3 行代码先引入再打印，结果输出是一个文件路径。第 4 行，bun 相当于集合了 wasirun 的功能，可以直接运行.wasm 文件。可以使用的功能及能查找的资料不多，期待 bun 后续版本的进一步更新吧。

3、读取环境变量 ​

有一些机密信息，例如数据库的帐号密码、API 的连接密钥，这些信息是不适合直接放在仓库中的，即使这个仓库是公司内部的私有仓库也不适宜直接放在仓库中。

一般的做法是这样的：

1）将机密信息存储在机器本地的.bashrc 或其它文件中，使用 export 关键字导出。在 macOS、Linux 系统上是使用 export 导出，在 Windows 上便是使用 set 导出。

2）为了统一操作与方便部署，在本地安装 dotnev 类库，然后在项目的根目录下创建一个.env 文件，这个文件里存储的是键值对。

bash
PORT=80
API_BASE_URL=https://domain:8080
PORT=80
API_BASE_URL=https://domain:8080

不需要使用 export 或 set，直接写键值对即可。然后在.gitignore 文件中忽略.env 使其不上传到仓库中，对于需要在本地测试的同学，直接私下发给他一份本地的.env 文件。本地测试环境、预发环境和线上环境需要使用不同的.env 文件，这样便于权限控制。

3）在项目中，在第一个文件中，先加载 dotenv 类库，然后马上调用它的 config 方法：

js
// pnpm install dotenv -S
const dotenv = require('dotenv')
dotenv.config()
// pnpm install dotenv -S
const dotenv = require('dotenv')
dotenv.config()

config 方法的作用只有一个，就是读取.env 文件，并将其写入到 process.env 对象上，这样后续的代码便可以直接访问环境变量了。

以上说的是老方法，在使用 bun 的项目工程中，不需要这么麻烦了。

dotenv 不需要手动安装了，我们可以认为，当我们安装了 bun 以后，dotenv 也随之自动安装了。然后我们可以直接编写本地的.env 文件，并在.gitignore 文件内忽略，再在 js 代码内通过 process.env 获取环境变量，等等，这些后续操作都是一样的了。

4、热加载 ​

热加载提升的是开发体验，前端开发尤其在调试 CSS 样式时，就是一个不断尝试新想法、然后查看效率不断修改的过程，如果每次都需要重启项目才能查看效率那太麻烦了。为此，热加载成为了前端项目高效开发的基础必备。

在 bun 之前，一般使用 nodemon 完成热加载需求。

js
npm install --save-dev nodemon
nodemon index.js // 代替 node
npm install --save-dev nodemon
nodemon index.js // 代替 node

在 bun 之后，不需要额外安装 nodemon 等工具类库了，bun 本身在启动时自带了热加载功能：

js
bun --watch server.ts
bun --hot server.ts
bun --watch server.ts
bun --hot server.ts

bun 的热加载一共有两种模式，watch 是硬加载，代码变动以后重启进程；而 hot 模式则只是重新加载受影响的代码，不重启进程。在开发中，有时候需要保护界面及数据现场，所以第二种 hot 模式便成为了首选。

补充：9月27日在Bun的官号上说，如果 Bun 在生产环境中的表现比贵公司的 Node 差，请发送电子邮件至 perf@oven.sh。看来 Bun 志在让 Node 归入历史。