Project Structure
The JavaScript standard does not specify a specification for the structure of the project. Generally speaking, all the files in a JavaScript library are usually placed in a folder named after the library. The following is a common JavaScript project specification:
.
+-- src/
| +-- project1.js
+-- styles/
| +-- style1.js
+-- examples/
| +-- some-example.js
+-- tests/
+-- some-integration-test.js
Cargo uses the following conventions for the package layout to make it easy to dive into a new Cargo package:
.
+-- Cargo.lock
+-- Cargo.toml
+-- src/
| +-- lib.rs
| +-- main.rs
+-- benches/
| +-- some-bench.rs
+-- examples/
| +-- some-example.rs
+-- tests/
+-- some-integration-test.rs
Cargo.toml
andCargo.lock
are stored in the root of the package.src/lib.rs
is the default library file, andsrc/main.rs
is the default executable file (see target auto-discovery).- Benchmarks go in the
benches
directory, integration tests go in thetests
directory (see testing, benchmarking). - Examples go in the
examples
directory. - There is no separate crate for unit tests, unit tests live in the same file as the code (see testing).
Managing large projects
For very large projects in Rust, Cargo offers workspaces to organize the project. A workspace can help manage multiple related packages that are developed in tandem. Some projects use virtual manifests, especially when there is no primary package.
Managing dependency versions
There is no concept of dependency in the JavaScript standard. However, some JavaScript runtimes, such as Node.js and Deno, have the concept of dependencies. When managing larger projects in Node.js, it may be appropriate to manage the versions of dependencies centrally, using strategies such as [nvm]. Deno uses [dvm]. Cargo introduced [workspace inheritance] to manage dependencies centrally. [nvm]: https://github.com/nvm-sh/nvm [dvm]: https://github.com/justjavac/dvm [workspace inheritance]: https://doc.rust-lang.org/cargo/reference/workspaces.html#the-package-table