rustlavel-cli 0.7.4

The rustlavel command-line tool: new, serve, make:*
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
80
81
82
83
84
85
86
87
88
89
90
91

# rustlavel-cli

The `rustlavel` command: scaffold an application, run it, generate the parts of it.

Part of [Rustlavel](https://github.com/advancedynamic/rustlavel), a full-stack web
framework for Rust written from scratch.

## Install

```sh
cargo install rustlavel-cli
```

## New applications

```sh
rustlavel new blog                  # asks what to put in
rustlavel new blog --with db,view   # or say so and skip the questions
rustlavel new app --with auth-kit   # sign-in, roles, audit trail, settings
```

## Generators

```sh
rustlavel make:module reports       # a feature that owns its routes and permissions
rustlavel make:crud Post --fields "title:string,body:text,done:bool"
rustlavel make:controller Post
rustlavel make:service Payroll
rustlavel make:model Post
rustlavel make:migration add_status_to_posts
```

`make:seeder`, `make:middleware`, `make:job`, `make:mail`, `make:notification`,
`make:mcp-tool`, `make:package` and `make:docker` are there too.

## Running an application

```sh
rustlavel serve                     # reloads when files change
rustlavel route:list --path admin   # also --method and --name
rustlavel migrate
rustlavel db:seed
rustlavel doctor                    # diagnoses why the app will not start
rustlavel build                     # the single deployable binary
```

Commands that need the application itself — `migrate`, `db:seed`, `route:list`,
`queue:work` — are forwarded to the project's own binary. **On a deployed machine
there is no cargo and no source, so you run that binary directly:**

```sh
./app migrate
./app db:seed
./app queue:work
```

That is why `rustlavel build` produces one file: it is the administration tool as well
as the server.

## Upgrading a project

The starter kit is copied into your application, so it does not move when the framework
does. This brings it forward:

```sh
rustlavel upgrade --dry-run        # say what would change, write nothing
rustlavel upgrade
rustlavel upgrade --from 0.5.0     # a project created before 0.7.2 has no manifest
```

It merges three versions of every file the kit owns: what the version in
`.rustlavel/manifest.json` wrote, what is in your project now, and what this CLI would
write. Where one side changed, that side wins. Where both changed, the file gets
`<<<<<<<` markers and the project stops compiling until you resolve it — deliberately,
because a half-applied upgrade found later is worse than a build that fails now.

The base is fetched from crates.io (with `curl` and `tar`, which is why `doctor` checks
for them) and cached. Your own files are never touched.

Going from 0.5.0 to 0.7.2 is a large jump and has a step-by-step runbook:
[Upgrading to 0.7.2](https://advancedynamic.github.io/rustlavel/guide.html#upgrading-to-0-7-2).
Read step 7 before you run `db:seed`.

## Documentation

- [The repository](https://github.com/advancedynamic/rustlavel)
- [The framework crate](https://crates.io/crates/rustlavel)

## Licence

MIT.