rcman 0.1.2

Framework-agnostic settings management with schema, backup/restore, secrets and derive macro support
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79

# Contributing to rcman

Thanks for considering contributing! This project aims to provide a robust, well-documented configuration manager for Rust applications.

## Workflow

1. Fork and create a feature branch.
2. Make focused changes with clear commit messages.
3. Ensure tests and lints pass locally.
4. Open a PR with a concise summary and rationale.

### Toolchain & MSRV

- Minimum Supported Rust Version (MSRV): 1.70 (declared in `Cargo.toml`).
- A `rust-toolchain.toml` pins the local channel to `stable` and installs `rustfmt` + `clippy`.

## Local Checks

Run these before pushing:

```bash
cargo fmt --all
cargo clippy --all-targets --all-features -- -D warnings
cargo test --all --all-features
```

### Pre-commit Hook (auto-run clippy)

Enable a git hook that runs clippy before every commit:

```bash
git config core.hooksPath .githooks
chmod +x .githooks/pre-commit
```

The hook runs `cargo clippy --all-targets --all-features -- -D warnings` and blocks commits on warnings.

## CI

- GitHub Actions runs format check, clippy (warnings = errors), tests.
- `cargo deny` checks licenses/advisories/duplicates.
- Docs are built with `RUSTDOCFLAGS=--cfg docsrs`.

## Helpful Tasks (just)

If you have `just` installed, common tasks are available:

```bash
just fmt
just clippy
just test
just docs
just deny
```

## Coding Guidelines

- Prefer returning `Result<T, Error>` over panicking.
- Avoid `unwrap()` in library code; handle lock poisoning by recovering guards.
- Keep functions small and focused; avoid unnecessary generics.
- Public APIs must have rustdoc comments and examples.
- Use `thiserror` to model error variants with helpful messages.

## Documentation

- Keep README focused on the most common tasks.
- Add doctests to public functions and modules when practical.
- Use feature-gated docs with `#[cfg_attr(docsrs, doc(cfg(feature = "...")))]` for optional features.

## Tests

- Write unit tests close to the code they cover.
- Favor integration tests for cross-module workflows (see `tests/`).
- In examples/tests, `unwrap()` is acceptable; in library code, prefer graceful errors.

## Changelog

- Update `CHANGELOG.md` under `[Unreleased]` for user-visible changes.
- Follow Keep a Changelog format.