fix: spell word (#66)

i18n/zh/docusaurus-plugin-content-docs/current/why-farm.md

@@ -5,21 +5,25 @@ sidebar_position: 2
 # 为什么需要 Farm？
 
 ## Farm 是什么？
+
 Farm 是一个非常快的基于 Rust 的 Web 构建工具，类似 `webpack` 和 `vite`，但**更快**。 farm `resolve, load, transform` 所有 `asset(js/jsx/ts/tsx、css/sass/less、html、静态资源、json 等)`，并将它们打包成一系列`可部署文件`。 Farm 是一个速度极快的构建工具，可帮助您构建更快的 `web/nodejs` 应用程序。
 
 ## 为什么需要 Farm？
+
 随着 web 项目规模的扩大，构建性能已经成为主要瓶颈，对于一个庞大的项目，使用 webpack 编译可能需要 10min 甚至更多，一次 hmr 更新可能需要 10s 甚至更多，严重降低了研发效率。
 
 因此我们急需极速的构建工具，解决项目编译性能问题。然后 vite/snowpack 这样的 unbundled 工具应运而生，此类工具主要有下面三个特性：
+
 1. 使用原生 ESM，在 dev server 启动时**不对**源文件进行编译和打包，源文件在入口模块执行时才会通过浏览器请求 dev server 编译，编译后的产物返回给浏览器
 2. HMR 时，只重新编译一个模块，这样 HMR 的时间约等于一个模块的编译时间
 3. 对外部依赖（如 node_modules 下的依赖）进行预打包
 
 这使得 dev 服务器热启动和 HMR 非常快，但 vite 等工具使用的 Unbundled 模式并不完美，对于大型项目来说仍然存在很大的问题：
-* **大量的模块请求**：对于一个大型项目，使用上述策略 1、2，首次启动可能需要加载数千个模块，使用原生模块系统加载数千个模块会导致浏览器卡住甚至崩溃。虽然 Dev Server 的启动快了，但是请求时的模块的首次编译依然会耗费大量时间，会有数十秒起步的白屏，编译时间只是转移了，并没有消失。
-* **开发和生产之间的不一致**：出于兼容性和请求数量、请求层级的考虑，原生 ES 模块在大多数情况下无法在生产中使用。 因此 vite 选择在生产环境选择用 rollup 打包。 这就带来了不一致，当这种不一致导致生产错误时，调试起来非常困难且非常痛苦。 而 vite 在 dev 中使用 esbuild，在生产中使用 rollup，这更加就放大了不一致性。
-* **拆包优化困难**： 受限于 Rollup，拆包配置不够灵活、易用。
-* 而 Vite 在 dev 上之所以这么快，esbuild 功不可没，它是用 go 编写的。 Go 利用了原生平台的优势，远快于 Js。
+
+- **大量的模块请求**：对于一个大型项目，使用上述策略 1、2，首次启动可能需要加载数千个模块，使用原生模块系统加载数千个模块会导致浏览器卡住甚至崩溃。虽然 Dev Server 的启动快了，但是请求时的模块的首次编译依然会耗费大量时间，会有数十秒起步的白屏，编译时间只是转移了，并没有消失。
+- **开发和生产之间的不一致**：出于兼容性和请求数量、请求层级的考虑，原生 ES 模块在大多数情况下无法在生产中使用。 因此 vite 选择在生产环境选择用 rollup 打包。 这就带来了不一致，当这种不一致导致生产错误时，调试起来非常困难且非常痛苦。 而 vite 在 dev 中使用 esbuild，在生产中使用 rollup，这更加就放大了不一致性。
+- **拆包优化困难**： 受限于 Rollup，拆包配置不够灵活、易用。
+- 而 Vite 在 dev 上之所以这么快，esbuild 功不可没，它是用 go 编写的。 Go 利用了原生平台的优势，远快于 Js。
 
 事实上，我们真正需要的是一个快速、强大、一致的 Web 构建工具，可以在解决上述问题的基础上，提供更加极致的编译效率。因此我们设计并开发了 Farm。
 
@@ -29,17 +33,15 @@ Farm 的设计主要都是针对 web 浏览器场景（包括 pc、移动、webv
 
 <!-- 但是如果使用 JS 编写构建工具，受限于 JS 单线程以及解释执行的限制，很难在现有的 JS 打包工具如 Rollup 或者 Webpack 基础上有很大的性能提升（当然有的构建工具比如 vite 在 dev 环境绕过打包，这种情况我们将在后文讨论）。因此我们需要引入原生语言的能力，Rust 就是一个非常好的选择，Rust 拥有内存安全、性能优秀等特性，同时 Rust 也有不少前端开源生态比如 SWC 编译器（SWC 可以简单理解为 Babel 的 Rust 替代），基于现有生态也能够更加方便地实现前端构建工具。 -->
 
-
 不过 Farm 不仅仅是一个用 Rust 重写的打包工具，它还有很多强大且先进的设计：
 
 ## Farm 设计理念
 
-* **性能优先**：一切都会用 Rust 编写，只有少数不是性能瓶颈的部分会用 JS 编写
-* **一致性有限**：默认情况下确保开发和生产完全相同，您在开发中看到的将与您在生产中得到的相同。
-* **局部打包**：Farm 的打包目标不是将所有东西打包在一起，而是限制资源的请求数量。 Farm会根据依赖关系和资源大小将您的项目捆绑成20-30个小资源，在不损失缓存粒度的情况下获得最佳的资源加载性能。
-* **所有资源视为一等公民**：Farm 不再需要将所有内容转换为 Javascript，它将任何内容视为一等公民，如 `html`、`js/jsx/ts/tsx`、`css/scss`、`png/svg/...`都是Farm支持的基础模块，更多类型的模块可以通过插件支持。
-* **兼容性**：Farm 将适用于旧版 (ES5) 和现代浏览器。
-* **Rollup 风格的插件系统**：轻松创建自己的插件，并轻松从 `rollup/vite/webpack` 迁移您的插件/项目。兼容 `Vite/Rollup/Unplugin` 插件
-
+- **性能优先**：一切都会用 Rust 编写，只有少数不是性能瓶颈的部分会用 JS 编写
+- **一致性**：默认情况下确保开发和生产完全相同，您在开发中看到的将与您在生产中得到的相同。
+- **局部打包**：Farm 的打包目标不是将所有东西打包在一起，而是限制资源的请求数量。 Farm 会根据依赖关系和资源大小将您的项目捆绑成 20-30 个小资源，在不损失缓存粒度的情况下获得最佳的资源加载性能。
+- **所有资源视为一等公民**：Farm 不再需要将所有内容转换为 Javascript，它将任何内容视为一等公民，如 `html`、`js/jsx/ts/tsx`、`css/scss`、`png/svg/...`都是 Farm 支持的基础模块，更多类型的模块可以通过插件支持。
+- **兼容性**：Farm 将适用于旧版 (ES5) 和现代浏览器。
+- **Rollup 风格的插件系统**：轻松创建自己的插件，并轻松从 `rollup/vite/webpack` 迁移您的插件/项目。兼容 `Vite/Rollup/Unplugin` 插件
 
-Farm 的目标是成为真正的下一代构建工具，快速、强大、一致，并为 Web 开发人员提供最佳的开发体验。
+Farm 的目标是成为真正的下一代构建工具，快速、强大、一致，并为 Web 开发人员提供最佳的开发体验。

i18n/zh/docusaurus-plugin-content-docs/version-0.x/why-farm.md

@@ -7,14 +7,16 @@ sidebar_position: 2
 随着 web 项目规模的扩大，构建性能已经成为主要瓶颈，对于一个庞大的项目，使用 webpack 编译可能需要 10min 甚至更多，一次 hmr 更新可能需要 10s 甚至更多，严重降低了研发效率。
 
 因此我们急需极速的构建工具，解决项目编译性能问题。然后 vite/snowpack 这样的 unbundled 工具应运而生，此类工具主要有下面三个特性：
+
 1. 使用原生 ESM，在 dev server 启动时**不对**源文件进行编译和打包，源文件在入口模块执行时才会通过浏览器请求 dev server 编译，编译后的产物返回给浏览器
 2. HMR 时，只重新编译一个模块，这样 HMR 的时间约等于一个模块的编译时间
 3. 对外部依赖（如 node_modules 下的依赖）进行预打包
 
 这使得 dev 服务器热启动和 HMR 非常快，但 vite 等工具使用的 Unbundled 模式并不完美，对于大型项目来说仍然存在很大的问题：
-* **大量的模块请求**：对于一个大型项目，使用上述策略 1、2，首次启动可能需要加载数千个模块，使用原生模块系统加载数千个模块会导致浏览器卡住甚至崩溃。虽然 Dev Server 的启动快了，但是请求时的模块的首次编译依然会耗费大量时间，会有数十秒起步的白屏，编译时间只是转移了，并没有消失。
-* **开发和生产之间的不一致**：出于兼容性和请求数量、请求层级的考虑，原生 ES 模块在大多数情况下无法在生产中使用。 因此 vite 选择在生产环境选择用 rollup 打包。 这就带来了不一致，当这种不一致导致生产错误时，调试起来非常困难且非常痛苦。 而 vite 在 dev 中使用 esbuild，在生产中使用 rollup，这更加就放大了不一致性。
-* 而 Vite 在 dev 上之所以这么快，esbuild 功不可没，它是用 go 编写的。 Go 利用了原生平台的优势，远快于 Js。
+
+- **大量的模块请求**：对于一个大型项目，使用上述策略 1、2，首次启动可能需要加载数千个模块，使用原生模块系统加载数千个模块会导致浏览器卡住甚至崩溃。虽然 Dev Server 的启动快了，但是请求时的模块的首次编译依然会耗费大量时间，会有数十秒起步的白屏，编译时间只是转移了，并没有消失。
+- **开发和生产之间的不一致**：出于兼容性和请求数量、请求层级的考虑，原生 ES 模块在大多数情况下无法在生产中使用。 因此 vite 选择在生产环境选择用 rollup 打包。 这就带来了不一致，当这种不一致导致生产错误时，调试起来非常困难且非常痛苦。 而 vite 在 dev 中使用 esbuild，在生产中使用 rollup，这更加就放大了不一致性。
+- 而 Vite 在 dev 上之所以这么快，esbuild 功不可没，它是用 go 编写的。 Go 利用了原生平台的优势，远快于 Js。
 
 事实上，我们真正需要的是一个快速、强大、一致的 Web 构建工具，可以在解决上述问题的基础上，提供更加极致的编译效率。因此我们开发了 Farm。
 
@@ -24,17 +26,15 @@ Farm 的设计主要都是针对 web 浏览器场景（包括 pc、移动、webv
 
 <!-- 但是如果使用 JS 编写构建工具，受限于 JS 单线程以及解释执行的限制，很难在现有的 JS 打包工具如 Rollup 或者 Webpack 基础上有很大的性能提升（当然有的构建工具比如 vite 在 dev 环境绕过打包，这种情况我们将在后文讨论）。因此我们需要引入原生语言的能力，Rust 就是一个非常好的选择，Rust 拥有内存安全、性能优秀等特性，同时 Rust 也有不少前端开源生态比如 SWC 编译器（SWC 可以简单理解为 Babel 的 Rust 替代），基于现有生态也能够更加方便地实现前端构建工具。 -->
 
-
 不过 Farm 不仅仅是一个用 Rust 重写的打包工具，它还有很多强大且先进的设计：
 
 ## Farm 设计理念
 
-* **性能优先**：一切都会用 Rust 编写，只有少数不是性能瓶颈的部分会用 JS 编写
-* **一致性有限**：默认情况下确保开发和生产完全相同，您在开发中看到的将与您在生产中得到的相同。
-* **局部打包**：Farm 的打包目标不是将所有东西打包在一起，而是限制资源的请求数量。 Farm会根据依赖关系和资源大小将您的项目捆绑成20-30个小资源，在不损失缓存粒度的情况下获得最佳的资源加载性能。
-* **所有资源视为一等公民**：Farm 不再需要将所有内容转换为 Javascript，它将任何内容视为一等公民，如 `html`、`js/jsx/ts/tsx`、`css/scss`、`png/svg/...`都是Farm支持的基础模块，更多类型的模块可以通过插件支持。
-* **兼容性**：Farm 将适用于旧版 (ES5) 和现代浏览器。
-* **Rollup 风格的插件系统**：轻松创建自己的插件，并轻松从 rollup/vite/webpack 迁移您的插件/项目。
-
+- **性能优先**：一切都会用 Rust 编写，只有少数不是性能瓶颈的部分会用 JS 编写
+- **一致性**：默认情况下确保开发和生产完全相同，您在开发中看到的将与您在生产中得到的相同。
+- **局部打包**：Farm 的打包目标不是将所有东西打包在一起，而是限制资源的请求数量。 Farm 会根据依赖关系和资源大小将您的项目捆绑成 20-30 个小资源，在不损失缓存粒度的情况下获得最佳的资源加载性能。
+- **所有资源视为一等公民**：Farm 不再需要将所有内容转换为 Javascript，它将任何内容视为一等公民，如 `html`、`js/jsx/ts/tsx`、`css/scss`、`png/svg/...`都是 Farm 支持的基础模块，更多类型的模块可以通过插件支持。
+- **兼容性**：Farm 将适用于旧版 (ES5) 和现代浏览器。
+- **Rollup 风格的插件系统**：轻松创建自己的插件，并轻松从 rollup/vite/webpack 迁移您的插件/项目。
 
-Farm 的目标是成为真正的下一代构建工具，快速、强大、一致，并为 Web 开发人员提供最佳的开发体验。
+Farm 的目标是成为真正的下一代构建工具，快速、强大、一致，并为 Web 开发人员提供最佳的开发体验。