Монорепозиторий с Rust: организация кода на практике

Онлайн-тренажер Python для начинающих

Изучайте Python легко и без перегрузки теорией. Решайте практические задачи с автоматической проверкой, получайте подсказки на русском языке и пишите код прямо в браузере — без необходимости что-либо устанавливать.

Начать курс

Монорепозиторий с Rust: организация кода на практике

При разработке крупных проектов на Rust рано или поздно встаёт вопрос: как организовать код, чтобы он оставался поддерживаемым, переиспользуемым и легко масштабируемым? Один из популярных подходов — монорепозиторий. В этой статье мы разберём, что такое монорепозиторий в контексте Rust, как его настроить с помощью Cargo Workspaces и какие практические приёмы помогут избежать хаоса в кодовой базе.

Материал будет полезен как новичкам, которые только начинают работать с большими проектами, так и опытным разработчикам, ищущим эффективные способы организации кода.

Что такое монорепозиторий и зачем он нужен в Rust?

Монорепозиторий (monorepo) — это подход, при котором весь код проекта (или нескольких связанных проектов) хранится в одном репозитории. В отличие от мультирепозиториев, где каждый сервис или библиотека живут в отдельном Git-репозитории.

Почему Rust-разработчики часто выбирают монорепозиторий?

Единая версия зависимостей. Вы избегаете конфликтов, когда разные крейты требуют разные версии одной и той же библиотеки.
Упрощённый рефакторинг. Изменение API в одном крейте сразу видно во всех зависимых крейтах — компилятор Rust укажет на все места, которые нужно поправить.
Совместная компиляция. Cargo может оптимизировать сборку, переиспользуя уже скомпилированные артефакты.
Единая история изменений. Вам не нужно синхронизировать коммиты между разными репозиториями.

Главный инструмент для организации монорепозитория в Rust — это Cargo Workspaces. Рассмотрим, как его использовать на практике.

Настройка Cargo Workspaces: пошаговый пример

Предположим, мы создаём приложение, состоящее из трёх частей:

библиотека core_lib — общая логика;
библиотека utils — утилиты;
исполняемый файл app — основной бинарник.

Создадим структуру монорепозитория:

my_monorepo/
├── Cargo.toml          # корневой манифест workspace
├── core_lib/
│   ├── Cargo.toml
│   └── src/
│       └── lib.rs
├── utils/
│   ├── Cargo.toml
│   └── src/
│       └── lib.rs
└── app/
    ├── Cargo.toml
    └── src/
        └── main.rs

Шаг 1. Корневой Cargo.toml

[workspace]
members = [
    "core_lib",
    "utils",
    "app",
]

Теперь все три крейта — часть одного workspace. Cargo будет управлять ими как единым целым.

Шаг 2. Внутренние зависимости

В файле app/Cargo.toml укажем, что он зависит от наших библиотек:

[package]
name = "app"
version = "0.1.0"
edition = "2021"

[dependencies]
core_lib = { path = "../core_lib" }
utils = { path = "../utils" }

Шаг 3. Написание кода

Пример кода в core_lib/src/lib.rs:

pub fn greet(name: &str) -> String {
    format!("Hello, {}!", name)
}

В app/src/main.rs используем эту функцию:

use core_lib::greet;

fn main() {
    println!("{}", greet("Rust Developer"));
}

Шаг 4. Сборка и запуск

Команды cargo build, cargo test и cargo run работают для всего workspace. Можно также запустить конкретный крейт:

cargo run -p app
cargo test -p core_lib

Это базовая настройка. Теперь перейдём к более продвинутым практикам.

Продвинутая организация: модули, тесты и версионирование

Когда крейтов становится больше, важно соблюдать дисциплину. Вот несколько проверенных приёмов:

1. Разделение на публичные и приватные модули

Используйте pub только для того, что действительно должно быть доступно снаружи. Внутренние модули прячьте с помощью pub(crate) или вообще без pub.

// core_lib/src/lib.rs
mod internal; // приватный модуль

pub use internal::helper; // реэкспорт только нужной функции

2. Использование feature flags

Если в монорепозитории есть общие библиотеки, которые используются по-разному, добавляйте фичи:

# core_lib/Cargo.toml
[features]
default = []
advanced = []

В коде:

#[cfg(feature = "advanced")]
pub fn advanced_function() { /* ... */ }

3. Тесты в монорепозитории

Размещайте тесты как внутри крейтов, так и в отдельных тестовых крейтах. Для интеграционных тестов можно создать папку tests/ в корне workspace:

my_monorepo/
└── tests/
    ├── Cargo.toml       # зависит от core_lib и utils
    └── integration_test.rs

Это позволяет тестировать взаимодействие между крейтами как единое целое.

4. Версионирование

Для внутренних крейтов используйте семантическое версионирование. Если крейт core_lib меняет публичный API, обновите его версию в Cargo.toml. Cargo предупредит, если зависимости несовместимы.