Skip to content

Commit 0574e4e

Browse files
committed
docs: Remove $ sign in code examples
1 parent 95e8d03 commit 0574e4e

25 files changed

+233
-98
lines changed

docs/01-get-started/01-creating-endpoints.md

Lines changed: 9 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -38,8 +38,8 @@ development:
3838
Next, we add the Dartantic AI package as a dependency to our server. This package provides a convenient interface for working with different AI providers, including Google's Gemini API.
3939
4040
```bash
41-
$ cd magic_recipe_server
42-
$ dart pub add dartantic_ai
41+
cd magic_recipe_server
42+
dart pub add dartantic_ai
4343
```
4444

4545
## Create a new endpoint
@@ -100,8 +100,8 @@ For methods to be recognized by Serverpod, they need to return a typed `Future`
100100
Now, you need to generate the code for your new endpoint. You do this by running `serverpod generate` in the server directory of your project:
101101

102102
```bash
103-
$ cd magic_recipe_server
104-
$ serverpod generate
103+
cd magic_recipe_server
104+
serverpod generate
105105
```
106106

107107
`serverpod generate` will create bindings for the endpoint and register them in the server's `generated/protocol.dart` file. It will also generate the required client code so that you can call your new `generateRecipe` method from your app.
@@ -221,16 +221,16 @@ Before you start your server, ensure no other Serverpod server is running. Also,
221221
Let's try our new recipe app! First, start the server:
222222

223223
```bash
224-
$ cd magic_recipe_server
225-
$ docker compose up -d
226-
$ dart bin/main.dart --apply-migrations
224+
cd magic_recipe_server
225+
docker compose up -d
226+
dart bin/main.dart --apply-migrations
227227
```
228228

229229
Now, you can start the Flutter app:
230230

231231
```bash
232-
$ cd magic_recipe_flutter
233-
$ flutter run -d chrome
232+
cd magic_recipe_flutter
233+
flutter run -d chrome
234234
```
235235

236236
This will start the Flutter app in your browser:

docs/01-get-started/02-models-and-data.md

Lines changed: 9 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -34,8 +34,8 @@ You can use most primitive Dart types here or any other models you have specifie
3434
To generate the code for the model, run the `serverpod generate` command in your server directory:
3535

3636
```bash
37-
$ cd magic_recipe_server
38-
$ serverpod generate
37+
cd magic_recipe_server
38+
serverpod generate
3939
```
4040

4141
This will generate the code for the model and create a new file called `recipe.dart` in the `lib/src/generated` directory. It will also update the client code in `magic_recipe/magic_recipe_client` so you can use it in your Flutter app.
@@ -133,8 +133,8 @@ class RecipeEndpoint extends Endpoint {
133133
First, we need to update our generated client by running `serverpod generate`.
134134

135135
```bash
136-
$ cd magic_recipe_server
137-
$ serverpod generate
136+
cd magic_recipe_server
137+
serverpod generate
138138
```
139139

140140
Now that we have created the `Recipe` model we can use it in the app. We will do this in the `_callGenerateRecipe` method of the `magic_recipe_flutter/lib/main.dart` file. Let's update our `RecipeWidget` so that it displays the author and year of the recipe in addition to the recipe itself.
@@ -433,16 +433,16 @@ class ResultDisplay extends StatelessWidget {
433433
First, start the server:
434434

435435
```bash
436-
$ cd magic_recipe_server
437-
$ docker compose up -d
438-
$ dart bin/main.dart
436+
cd magic_recipe_server
437+
docker compose up -d
438+
dart bin/main.dart
439439
```
440440

441441
Then, start the Flutter app:
442442

443443
```bash
444-
$ cd magic_recipe_flutter
445-
$ flutter run -d chrome
444+
cd magic_recipe_flutter
445+
flutter run -d chrome
446446
```
447447

448448
This will start the Flutter app in your browser. It should look something like this:

docs/01-get-started/03-working-with-the-database.md

Lines changed: 10 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -42,9 +42,9 @@ To create a migration, follow these two steps in order:
4242
2. Run `serverpod create-migration` to create the necessary database migration.
4343

4444
```bash
45-
$ cd magic_recipe_server
46-
$ serverpod generate
47-
$ serverpod create-migration
45+
cd magic_recipe_server
46+
serverpod generate
47+
serverpod create-migration
4848
```
4949

5050
Each time you run `serverpod create-migration`, a new migration file will be created in your _migrations_ folder. These step-by-step migrations provide a history of your database changes and allow you to roll back changes if needed.
@@ -190,8 +190,8 @@ The `insertRow` method is used to insert a new row into the database. The `find`
190190
Like before, when you change something that has an effect on your client code, you need to run `serverpod generate`. We don't need to run `serverpod create-migrations` again because we already created a migration in the previous step and haven't done any changes that affect the database.
191191

192192
```bash
193-
$ cd magic_recipe_server
194-
$ serverpod generate
193+
cd magic_recipe_server
194+
serverpod generate
195195
```
196196

197197
## Call the endpoint from the app
@@ -434,9 +434,9 @@ To run the application with database support, follow these steps in order:
434434
First, start the database and apply migrations:
435435

436436
```bash
437-
$ cd magic_recipe_server
438-
$ docker compose up -d # Start the database container
439-
$ dart bin/main.dart --apply-migrations # Apply any pending migrations
437+
cd magic_recipe_server
438+
docker compose up -d # Start the database container
439+
dart bin/main.dart --apply-migrations # Apply any pending migrations
440440
```
441441

442442
:::tip
@@ -446,8 +446,8 @@ The `--apply-migrations` flag is safe to use during development - if no migratio
446446
Next, launch the Flutter app:
447447

448448
```bash
449-
$ cd magic_recipe_flutter
450-
$ flutter run -d chrome
449+
cd magic_recipe_flutter
450+
flutter run -d chrome
451451
```
452452

453453
## Summary

docs/06-concepts/06-database/01-connection.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -100,19 +100,19 @@ development:
100100
A newly created Serverpod project has a preconfigured Docker instance with a Postgres database set up. Run the following command from the root of the `server` package to start the database:
101101

102102
```bash
103-
$ docker compose up --build --detach
103+
docker compose up --build --detach
104104
```
105105

106106
To stop the database run:
107107

108108
```bash
109-
$ docker compose stop
109+
docker compose stop
110110
```
111111

112112
To remove the database and __delete__ all associated data, run:
113113

114114
```bash
115-
$ docker compose down -v
115+
docker compose down -v
116116
```
117117

118118
## Connecting to a custom Postgres instance

docs/06-concepts/06-database/11-migrations.md

Lines changed: 14 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -28,7 +28,7 @@ If you want to transition a manually managed table to then be managed by Serverp
2828
To create a migration navigate to your project's `server` package directory and run the `create-migration` command.
2929

3030
```bash
31-
$ serverpod create-migration
31+
serverpod create-migration
3232
```
3333

3434
The command reads the database schema from the last migration, then compares it to the database schema necessary to accommodate the projects, and any module dependencies, current database requirements. If differences are identified, a new migration is created in the `migrations` directory to roll the database forward.
@@ -47,15 +47,15 @@ The migration command aborts and displays an error under two conditions:
4747
To override these safeguards and force the creation of a migration, use the `--force` flag.
4848

4949
```bash
50-
$ serverpod create-migration --force
50+
serverpod create-migration --force
5151
```
5252

5353
### Tag migration
5454

5555
Tags can be useful to identify migrations that introduced specific changes to the project. Tags are appended to the migration name and can be added with the `--tag` option.
5656

5757
```bash
58-
$ serverpod create-migration --tag "v1-0-0"
58+
serverpod create-migration --tag "v1-0-0"
5959
```
6060

6161
This would create a migration named `<timestamp>-v1-0-0`:
@@ -97,13 +97,13 @@ For each migration, five files are created:
9797
Migrations are applied using the server runtime. To apply migrations, navigate to your project's `server` package directory, then start the server with the `--apply-migrations` flag. Migrations are applied as part of the startup sequence and the framework asserts that each migration is only applied once to the database.
9898

9999
```bash
100-
$ dart run bin/main.dart --apply-migrations
100+
dart run bin/main.dart --apply-migrations
101101
```
102102

103103
Migrations can also be applied using the maintenance role. In maintenance, after migrations are applied, the server exits with an exit code indicating if migrations were successfully applied, zero for success or non-zero for failure.
104104

105105
```bash
106-
$ dart run bin/main.dart --role maintenance --apply-migrations
106+
dart run bin/main.dart --role maintenance --apply-migrations
107107
```
108108

109109
This is useful if migrations are applied as part of an automated process.
@@ -119,7 +119,7 @@ By default, the command connects to and pulls a live database schema from a runn
119119
To create a repair migration, navigate to your project's `server` package directory and run the `create-repair-migration` command.
120120

121121
```bash
122-
$ serverpod create-repair-migration
122+
serverpod create-repair-migration
123123
```
124124

125125
This creates a repair migration in the `repair-migration` directory targeting the project's latest migration.
@@ -137,7 +137,7 @@ Since each repair migration is created for a specific live database schema, Serv
137137
By default, the repair migration system connects to your `development` database using the information specified in your Serverpod config. To use a different database source, the `--mode` option is used.
138138

139139
```bash
140-
$ serverpod create-repair-migration --mode production
140+
serverpod create-repair-migration --mode production
141141
```
142142

143143
The command connects and pulls the live database schema from a running server.
@@ -147,7 +147,7 @@ The command connects and pulls the live database schema from a running server.
147147
Repair migrations can also target a specific migration version by specifying the migration name with the `--version` option.
148148

149149
```bash
150-
$ serverpod create-repair-migration --version 20230821135718-v1-0-0
150+
serverpod create-repair-migration --version 20230821135718-v1-0-0
151151
```
152152

153153
This makes it possible to revert your database schema back to any older migration version.
@@ -162,15 +162,15 @@ The repair migration command aborts and displays an error under two conditions:
162162
To override these safeguards and force the creation of a repair migration, use the `--force` flag.
163163

164164
```bash
165-
$ serverpod create-repair-migration --force
165+
serverpod create-repair-migration --force
166166
```
167167

168168
### Tag repair migration
169169

170170
Repair migrations can be tagged just like regular migrations. Tags are appended to the migration name and can be added with the `--tag` option.
171171

172172
```bash
173-
$ serverpod create-repair-migration --tag "reset-migrations"
173+
serverpod create-repair-migration --tag "reset-migrations"
174174
```
175175

176176
This would create a repair migration named `<timestamp>-reset-migrations` in the `repair` directory:
@@ -194,13 +194,13 @@ The `repair` directory only exists if a repair migration has been created and co
194194
The repair migration is applied using the server runtime. To apply a repair migration, start the server with the `--apply-repair-migration` flag. The repair migration is applied as part of the startup sequence and the framework asserts that each repair migration is only applied once to the database.
195195

196196
```bash
197-
$ dart run bin/main.dart --apply-repair-migration
197+
dart run bin/main.dart --apply-repair-migration
198198
```
199199

200200
The repair migration can also be applied using the maintenance role. In maintenance, after migrations are applied, the server exits with an exit code indicating if migrations were successfully applied, zero for success or non-zero for failure.
201201

202202
```bash
203-
$ dart run bin/main.dart --role maintenance --apply-repair-migration
203+
dart run bin/main.dart --role maintenance --apply-repair-migration
204204
```
205205

206206
If a repair migration is applied at the same time as migrations, the repair migration is applied first.
@@ -214,11 +214,11 @@ Note that data is not rolled back, only the database schema.
214214
To roll back to a previous migration, first create a repair migration targeting the desired migration version:
215215

216216
```bash
217-
$ serverpod create-repair-migration --version 20230821135718-v1-0-0 --tag "roll-back-to-v1-0-0"
217+
serverpod create-repair-migration --version 20230821135718-v1-0-0 --tag "roll-back-to-v1-0-0"
218218
```
219219

220220
Then apply the repair migration, any repair migration will only be applied once:
221221

222222
```bash
223-
$ dart run bin/main.dart --apply-repair-migration
223+
dart run bin/main.dart --apply-repair-migration
224224
```

docs/06-concepts/10-modules.md

Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -32,15 +32,15 @@ modules:
3232
Then run `pub get` and `serverpod generate` from your server's directory (e.g., `mypod_server`) to add the module to your project's deserializer.
3333

3434
```bash
35-
$ dart pub get
36-
$ serverpod generate
35+
dart pub get
36+
serverpod generate
3737
```
3838

3939
Finally, since modules might include modifications to the database schema, you should create a new database migration and apply it by running `serverpod create-migration` then `dart bin/main.dart --apply-migrations` from your server's directory.
4040

4141
```bash
42-
$ serverpod create-migration
43-
$ dart bin/main.dart --apply-migrations
42+
serverpod create-migration
43+
dart bin/main.dart --apply-migrations
4444
```
4545

4646
### Client setup
@@ -79,13 +79,13 @@ fields:
7979
With the `serverpod create` command, it is possible to create new modules for code that is shared between projects or that you want to publish to pub.dev. To create a module instead of a server project, pass `module` to the `--template` flag.
8080

8181
```bash
82-
$ serverpod create --template module my_module
82+
serverpod create --template module my_module
8383
```
8484

8585
The create command will create a server and a client Dart package. If you also want to add custom Flutter code, use `flutter create` to create a package.
8686

8787
```bash
88-
$ flutter create --template package my_module_flutter
88+
flutter create --template package my_module_flutter
8989
```
9090

9191
In your Flutter package, you most likely want to import the client libraries created by `serverpod create`.

docs/06-concepts/11-authentication/04-providers/03-google/01-setup.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -190,7 +190,7 @@ If your `google-services.json` does not include a web OAuth client entry, you ma
190190
For a production app you need to get the SHA-1 key from your production keystore! This can be done by running this command: ([Read more](https://support.google.com/cloud/answer/6158849#installedapplications&android&zippy=%2Cnative-applications%2Candroid)).
191191

192192
```bash
193-
$ keytool -list -v -keystore /path/to/keystore
193+
keytool -list -v -keystore /path/to/keystore
194194
```
195195
:::
196196

@@ -208,7 +208,7 @@ Navigate to _Clients_ and select the server credentials (the one configured as a
208208
Force flutter to run on a specific port by running.
209209

210210
```bash
211-
$ flutter run -d chrome --web-port=49660
211+
flutter run -d chrome --web-port=49660
212212
```
213213
:::
214214

docs/06-concepts/11-authentication/11-legacy/01-setup.md

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -15,7 +15,7 @@ Serverpod's auth module makes it easy to authenticate users through email or 3rd
1515
Add the module as a dependency to the server project's `pubspec.yaml`.
1616

1717
```sh
18-
$ dart pub add serverpod_auth_server
18+
dart pub add serverpod_auth_server
1919
```
2020

2121
Add the authentication handler to the Serverpod instance.
@@ -46,27 +46,27 @@ modules:
4646
While still in the server project, generate the client code and endpoint methods for the auth module by running the `serverpod generate` command line tool.
4747

4848
```bash
49-
$ serverpod generate
49+
serverpod generate
5050
```
5151

5252
### Initialize the auth database
5353

5454
After adding the module to the server project, you need to initialize the database. First you have to create a new migration that includes the auth module tables. This is done by running the `serverpod create-migration` command line tool in the server project.
5555

5656
```bash
57-
$ serverpod create-migration
57+
serverpod create-migration
5858
```
5959

6060
Start your database container from the server project.
6161

6262
```bash
63-
$ docker compose up --build --detach
63+
docker compose up --build --detach
6464
```
6565

6666
Then apply the migration by starting the server with the `apply-migrations` flag.
6767

6868
```bash
69-
$ dart run bin/main.dart --role maintenance --apply-migrations
69+
dart run bin/main.dart --role maintenance --apply-migrations
7070
```
7171

7272
The full migration instructions can be found in the [migration guide](../../database/migrations).

docs/06-concepts/11-authentication/11-legacy/04-providers/02-google.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -119,7 +119,7 @@ Put the file inside the `android/app/` directory and rename it to `google-servic
119119
For a production app you need to get the SHA-1 key from your production keystore! This can be done by running this command: ([Read more](https://support.google.com/cloud/answer/6158849#installedapplications&android&zippy=%2Cnative-applications%2Candroid)).
120120

121121
```bash
122-
$ keytool -list -v -keystore /path/to/keystore
122+
keytool -list -v -keystore /path/to/keystore
123123
```
124124

125125
:::
@@ -136,7 +136,7 @@ Navigate to _Credentials_ under _APIs & Services_ and select the server credenti
136136
Force flutter to run on a specific port by running.
137137

138138
```bash
139-
$ flutter run -d chrome --web-port=49660
139+
flutter run -d chrome --web-port=49660
140140
```
141141

142142
:::

0 commit comments

Comments
 (0)