docs: take advantage of new docs.page features (#464)

README.md

@@ -0,0 +1 @@
+./packages/melos/README.md

docs/commands/bootstrap.mdx

@@ -1,13 +1,14 @@
 ---
 title: Bootstrap Command
-description: "Learn more about the `bootstrap` command in Melos."
+description: Learn more about the `bootstrap` command in Melos.
 ---
 
 # Bootstrap Command
 
-> Supports all [Melos filtering](/filters) flags.
+<Info>Supports all [Melos filtering](/filters) flags.</Info>
 
-This command initializes the workspace, links local packages together and installs remaining package dependencies.
+This command initializes the workspace, links local packages together and
+installs remaining package dependencies.
 
 ```bash
 melos bootstrap
@@ -18,33 +19,64 @@ melos bs
 Bootstrapping has two primary functions:
 
 1. Installing all package dependencies (internally using `pub get`).
-2. Locally linking any packages together via path dependency overrides _without having to edit your pubspec.yaml_.
+2. Locally linking any packages together via path dependency overrides _without
+   having to edit your pubspec.yaml_.
 
 ## Why is bootstrapping required?
 
-In normal projects, packages can be linked by providing a `path` within the `pubspec.yaml`. This works for small
-projects however presents a problem at scale. Packages cannot be published with a locally defined path, meaning
-once you're ready to publish your packages you'll need to manually update all the packages `pubspec.yaml` files
-with the versions. If your packages are also tightly coupled (dependencies of each other), you'll also have to manually
-check which versions should be updated. Even with a few of packages this can become a long and error-prone task.
+In normal projects, packages can be linked by providing a `path` within the
+`pubspec.yaml`. This works for small projects however presents a problem at
+scale. Packages cannot be published with a locally defined path, meaning once
+you're ready to publish your packages you'll need to manually update all the
+packages `pubspec.yaml` files with the versions. If your packages are also
+tightly coupled (dependencies of each other), you'll also have to manually check
+which versions should be updated. Even with a few of packages this can become a
+long and error-prone task.
 
-Melos solves this problem by overriding local files which the Dart analyzer uses to read packages from. If a local package
-exists (defined in the `melos.yaml` file) and a different local package has it listed as a dependency, it will be linked
-regardless of whether a version has been specified.
+Melos solves this problem by overriding local files which the Dart analyzer uses
+to read packages from. If a local package exists (defined in the `melos.yaml`
+file) and a different local package has it listed as a dependency, it will be
+linked regardless of whether a version has been specified.
 
 ### Benefits
 
-- All local packages in the repository can be interlinked by Melos to point to their local directories rather than 'remote' _without pubspec.yaml modifications_.
-  - **Example Scenario**: In a repository, package `A` depends on package `B`. Both packages `A` & `B` exist in the monorepo. However, if you `pub get` inside package `A`, `pub` will retrieve package `B` from the pub.dev registry as it's unaware of `B` existing locally. However, with Melos, it's aware that package `B` exists locally too, so it will generate the various pub files to point to a relative path in the local repository.
-    - If you wanted to use pub you could of course define a dependency override in the pubspec of package `A` that sets a path for package `B` but, then you'd have to do this manually every time and then manually remove it again when you want to publish or even commit your changes. This doesn't scale well and doesn't help with making a repository contributor friendly. [FlutterFire](https://github.com/FirebaseExtended/flutterfire) for example has over 40 packages with various interlinking levels (try run `melos list --graph` to see its local dependency graph).
-      - This can also get phenomenally worse for example say if we introduce package `C` that package `B` depends on but package `C` then also depends on `A`.
+- All local packages in the repository can be interlinked by Melos to point to
+  their local directories rather than 'remote' _without pubspec.yaml
+  modifications_.
+  - **Example Scenario**: In a repository, package `A` depends on package `B`.
+    Both packages `A` & `B` exist in the monorepo. However, if you `pub get`
+    inside package `A`, `pub` will retrieve package `B` from the pub.dev
+    registry as it's unaware of `B` existing locally. However, with Melos, it's
+    aware that package `B` exists locally too, so it will generate the various
+    pub files to point to a relative path in the local repository.
+    - If you wanted to use pub you could of course define a dependency override
+      in the pubspec of package `A` that sets a path for package `B` but, then
+      you'd have to do this manually every time and then manually remove it
+      again when you want to publish or even commit your changes. This doesn't
+      scale well and doesn't help with making a repository contributor friendly.
+      [FlutterFire](https://github.com/FirebaseExtended/flutterfire) for example
+      has over 40 packages with various interlinking levels (try run
+      `melos list --graph` to see its local dependency graph).
+      - This can also get phenomenally worse for example say if we introduce
+        package `C` that package `B` depends on but package `C` then also
+        depends on `A`.
 - Interlinking highlights dart/analyzer issues early.
-  - **Example Scenario**: Package `A` relies on package `B` from the same mono repo. Package `B` gets a minor API change. Via `pub get` on package `A` the dart analyzer and IDEs report no issues with the package as it installed package `B` from the remote pub registry and not local (which hasn't been published yet). With Melos, the dart analyzer / IDEs would highlight this issue immediately since local versions are used. The same applies for non-breaking deprecations, package `A` wouldn't show there was a deprecated API in use without being interlinked through Melos.
-- Interlinking allows working on new, not yet published (or private) packages easily, without defining dependency overrides.
+  - **Example Scenario**: Package `A` relies on package `B` from the same mono
+    repo. Package `B` gets a minor API change. Via `pub get` on package `A` the
+    dart analyzer and IDEs report no issues with the package as it installed
+    package `B` from the remote pub registry and not local (which hasn't been
+    published yet). With Melos, the dart analyzer / IDEs would highlight this
+    issue immediately since local versions are used. The same applies for
+    non-breaking deprecations, package `A` wouldn't show there was a deprecated
+    API in use without being interlinked through Melos.
+- Interlinking allows working on new, not yet published (or private) packages
+  easily, without defining dependency overrides.
 
 ## Combining with filters
 
-Bootstrap supports [all package filtering options](/filters), therefore if you wanted to you could bootstrap only a specific subset of your packages, for example:
+Bootstrap supports [all package filtering options](/filters), therefore if you
+wanted to you could bootstrap only a specific subset of your packages, for
+example:
 
 ```bash
 # Only bootstrap packages that have
@@ -54,10 +86,11 @@ melos bootstrap --diff="main"
 
 ## Adding a postbootstrap lifecycle script
 
-Melos supports various command [lifecycle hooks](/configuration/scripts#hooks) that can be defined in your `melos.yaml`.
+Melos supports various command [lifecycle hooks](/configuration/scripts#hooks)
+that can be defined in your `melos.yaml`.
 
-For example, if you needed to run something such as a build runner automatically after `melos bootstrap` is run, you can add a
-`postBootstrap` script:
+For example, if you needed to run something such as a build runner automatically
+after `melos bootstrap` is run, you can add a `postBootstrap` script:
 
 ```yaml
 # melos.yaml
@@ -67,5 +100,6 @@ scripts:
 # ...
 ```
 
-This is useful to ensure any local project requirements, such as generated files being built, are met when anyone is working on
-your mono repo code base, e.g. external contributors.
+This is useful to ensure any local project requirements, such as generated files
+being built, are met when anyone is working on your mono repo code base, e.g.
+external contributors.

docs/commands/clean.mdx

@@ -1,13 +1,14 @@
 ---
 title: Clean Command
-description: "Learn more about the `clean` command in Melos."
+description: Learn more about the `clean` command in Melos.
 ---
 
 # Clean Command
 
-> Supports all [Melos filtering](/filters) flags.
+<Info>Supports all [Melos filtering](/filters) flags.</Info>
 
-This command cleans the current workspace and all its packages of temporary pub & generated Melos IDE files.
+This command cleans the current workspace and all its packages of temporary pub
+& generated Melos IDE files.
 
 ```bash
 melos clean
@@ -32,7 +33,8 @@ melos bootstrap
 
 ## Combining with filters
 
-Clean supports [all package filtering options](/filters), therefore if you wanted to you could clean only a specific subset of your packages, for example:
+Clean supports [all package filtering options](/filters), therefore if you
+wanted to you could clean only a specific subset of your packages, for example:
 
 ```bash
 # Only clean Flutter packages or apps.
@@ -41,9 +43,12 @@ melos clean --flutter
 
 ## Adding a postclean lifecycle script
 
-Melos supports various command lifecycle hooks that can be defined in your `melos.yaml`.
+Melos supports various command lifecycle hooks that can be defined in your
+`melos.yaml`.
 
-For example, if you needed to cleanup any generated files, e.g. from a build runner, automatically after `melos clean` is ran, you can add a `postClean` script.
+For example, if you needed to cleanup any generated files, e.g. from a build
+runner, automatically after `melos clean` is ran, you can add a `postClean`
+script.
 
 ```yaml
 # melos.yaml

docs/commands/exec.mdx

@@ -1,11 +1,11 @@
 ---
 title: Exec Command
-description: "Learn more about the `exec` command in Melos."
+description: Learn more about the `exec` command in Melos.
 ---
 
 # Exec Command
 
-> Supports all [Melos filtering](/filters) flags.
+<Info>Supports all [Melos filtering](/filters) flags.</Info>
 
 Execute an arbitrary command in each package.
 
@@ -14,22 +14,23 @@ melos exec
 # e.g. melos exec -- pub global run tuneup check
 ```
 
-The command is executed in a shell. On Windows the shell is `cmd.exe` and on all other platforms
-it is `sh`.
+The command is executed in a shell. On Windows the shell is `cmd.exe` and on all
+other platforms it is `sh`.
 
-If multiple commands are being executed and no further commands should be executed
-after a command has failed, connect the commands with `&&`:
+If multiple commands are being executed and no further commands should be
+executed after a command has failed, connect the commands with `&&`:
 
 ```shell
 melos exec -- "melos bootstrap && melos run build"
 ```
 
-It is important to pass multiple commands as a single string to `melos exec`, otherwise the shell
-will pass only the first command to `melos exec`.
+It is important to pass multiple commands as a single string to `melos exec`,
+otherwise the shell will pass only the first command to `melos exec`.
 
 ## concurrency (-c)
 
-Defines the max concurrency value of how many packages will execute the command in at any one time. Defaults to `5`.
+Defines the max concurrency value of how many packages will execute the command
+in at any one time. Defaults to `5`.
 
 ```bash
 # Set a 1 concurrency
@@ -38,8 +39,8 @@ melos exec -c 1  -- "dart analyze ."
 
 ## --fail-fast
 
-Whether exec should fail fast and not execute the script in further packages if the script fails in an individual package.
-Defaults to `false`.
+Whether exec should fail fast and not execute the script in further packages if
+the script fails in an individual package. Defaults to `false`.
 
 ```bash
 # Fail fast

docs/commands/list.mdx

@@ -1,11 +1,11 @@
 ---
 title: List Command
-description: "Learn more about the `list` command in Melos."
+description: Learn more about the `list` command in Melos.
 ---
 
 # List Command
 
-> Supports all [Melos filtering](/filters) flags.
+<Info>Supports all [Melos filtering](/filters) flags.</Info>
 
 List information about the local packages.
 
@@ -33,7 +33,8 @@ melos list -a
 
 ## --relative (-r)
 
-When printing output, use package paths relative to the root of the workspace. Defaults to `false` (or full paths).
+When printing output, use package paths relative to the root of the workspace.
+Defaults to `false` (or full paths).
 
 ```bash
 melos list --relative

docs/commands/publish.mdx

@@ -1,21 +1,23 @@
 ---
 title: Publish Command
-description: "Learn more about the `publish` command in Melos."
+description: Learn more about the `publish` command in Melos.
 ---
 
 # Publish Command
 
-> Supports all [Melos filtering](/filters) flags.
+<Info>Supports all [Melos filtering](/filters) flags.</Info>
 
-Publish any unpublished packages or package versions in your repository to pub.dev. `dry-run` is enabled by default.
+Publish any unpublished packages or package versions in your repository to
+pub.dev. `dry-run` is enabled by default.
 
 ```bash
 melos publish
 ```
 
 ## --dry-run
 
-Flags whether to publish the packages as a dry run (validate but do not publish). Defaults to `true`.
+Flags whether to publish the packages as a dry run (validate but do not
+publish). Defaults to `true`.
 
 ```bash
 # Publish packages with dry run
@@ -27,18 +29,23 @@ melos publish --no-dry-run
 
 Use `--no-dry-run` to disable.
 
-Publish any unpublished packages or package versions in your repository to pub.dev. `dry-run` is enabled by default.
+Publish any unpublished packages or package versions in your repository to
+pub.dev. `dry-run` is enabled by default.
 
 ```bash
 melos publish
 ```
 
 ## --git-tag-version (-t)
 
-Add any missing git tags for release. Tags are only created if --no-dry-run is also set.
+Add any missing git tags for release. Tags are only created if --no-dry-run is
+also set.
 
 ```bash
 melos publish --no-dry-run --git-tag-version
 ```
 
-Note that tags are automatically created as part of `melos version` (unless `--no-git-tag-version` is specified when running the version command) so this is usually not required on `melos publish` unless you're doing a manual version and publish of packages.
+Note that tags are automatically created as part of `melos version` (unless
+`--no-git-tag-version` is specified when running the version command) so this is
+usually not required on `melos publish` unless you're doing a manual version and
+publish of packages.

docs/commands/run.mdx

@@ -1,6 +1,6 @@
 ---
 title: Run Command
-description: 'Learn more about the `run` command in Melos.'
+description: Learn more about the `run` command in Melos.
 ---
 
 # Run Command