编码风格

¥Coding Style

我们建议在编写 Rolldown 代码时遵循以下准则。这些规则并不十分严格，因为我们希望灵活变通，并且我们理解在某些情况下，其中一些规则可能会适得其反。请尽量遵循以下说明：

¥We recommend to follow these guidelines when writing code for rolldown. They aren't very strict rules since we want to be flexible and we understand that under certain circumstances some of them can be counterproductive. Just try to follow as many of them as possible:

命名

¥Namings

Rust

我们倾向于遵循 Rust API 指南 的建议。它们主要由 Rust 库团队编写，基于构建 Rust 标准库和 Rust 生态系统中其他 crate 的经验。

¥We tend to follow the suggestions of Rust API Guidelines. They are authored largely by the Rust library team, based on experiences building the Rust standard library and other crates in the Rust ecosystem.

我们理解有些情况下规则不适用，但你应该尽可能地遵循它们。

¥We understand that there are cases that rules don't apply, but you should try to follow them as much as possible.

添加测试

¥Adding tests

在生成过程中，我们有两个环境用于运行不同目的的测试。有关更多信息，请参阅 测试。

¥In generate, we have two environments for running different purposes of tests. See Testing for more information.

我们建议你首先考虑在 Rust 端添加测试，因为

¥We enquire that you should first considering adding tests in Rust side, because

• 它具有更好的调试支持，无需考虑 Rust 和 JavaScript 之间的桥接。

  ¥It has better debugging support without considering bridge between Rust and JavaScript.

• 由于无需编译绑定 crate 并运行 Node.js，因此开发周期更快。

  ¥It has faster development cycle due to no need to compile the binding crate and run Node.js.

你可以考虑在 Node.js 中添加测试，原因如下：

¥You could consider adding tests in Node.js with the following reasons:

• 测试是关于 JavaScript API 的行为。

  ¥The test is about the behavior of the JavaScript API.

• 测试是关于 rolldown 包本身的行为。

  ¥The test is about the behavior of the rolldown package itself.

• 端到端测试。

  ¥E2E tests.