update docs to match new build script + fixes

Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>

docs/deployment/docker.md

@@ -34,8 +34,8 @@ more efficient caching of dependencies on the host, where a single change won't
 bust the entire cache.
 
 The required steps in the host build are to install dependencies with
-`yarn install`, generate type definitions using `yarn tsc`, and build all
-packages with `yarn build`.
+`yarn install`, generate type definitions using `yarn tsc`, and build the backend
+package with `yarn build:backend`.
 
 > NOTE: If you created your app prior to 2021-02-18, follow the
 > [migration step](https://github.com/backstage/backstage/releases/tag/release-2021-02-18)
@@ -49,8 +49,8 @@ yarn install --frozen-lockfile
 # tsc outputs type definitions to dist-types/ in the repo root, which are then consumed by the build
 yarn tsc
 
-# Build all packages and in the end bundle them all up into the packages/backend/dist folder.
-yarn build
+# Build the backend, which bundles it all up into the packages/backend/dist folder.
+yarn build:backend
 ```
 
 Once the host build is complete, we are ready to build our image. The following

docs/getting-started/contributors.md

@@ -101,7 +101,8 @@ yarn workspace @backstage/plugin-api-docs start # Serve api-docs plugin only, al
 yarn tsc # Run typecheck, use --watch for watch mode
 yarn tsc:full # Run full type checking, for example without skipLibCheck, use in CI
 
-yarn build # Build published versions of packages, depends on tsc
+yarn build:backend # Build the backend package, depends on tsc
+yarn build:all # Build published versions of packages, depends on tsc
 
 yarn lint # lint packages that have changed since later commit on origin/master
 yarn lint:all # lint all packages

docs/getting-started/running-backstage-locally.md

@@ -41,47 +41,38 @@ locally to use features like Software Templates and TechDocs. Please refer to
 the
 [installation instructions for Docker](https://docs.docker.com/engine/install/).
 
-## Clone and Build
+## Clone and Install
 
 To get up and running with a local Backstage to evaluate it, let's clone it off
-of GitHub and run an initial build.
+of GitHub and run an initial install.
 
 ```bash
 # Start from your local development folder
 git clone --depth 1 git@github.com:backstage/backstage.git
 cd backstage
 
-# Fetch our dependencies and run an initial build
+# Install our dependencies
 yarn install
-yarn tsc
-yarn build
 ```
 
 Phew! Now you have a local repository that's ready to run and to add any open
 source contributions into.
 
 We are now going to launch two things: an example Backstage frontend app, and an
-example Backstage backend that the frontend talks to. You are going to need two
-terminal windows, both starting from the Backstage project root.
-
-In the first window, run
+example Backstage backend that the frontend talks to. These can both be launched
+through the following command:
 
 ```bash
-# From your Backstage root directory
-yarn --cwd packages/backend start
+# From your Backstage root directory, launches both the frontend and backend
+yarn dev
 ```
 
-That starts up a backend instance on port 7007.
+If you prefer to run the frontend and backend separately, you can instead use `yarn start`
+and `yarn start-backend` in two separate terminal windows.
 
-In the other window, we will then launch the frontend. This command is run from
-the project root, not inside the backend directory.
-
-```bash
-yarn start
-```
-
-That starts up the frontend on port 3000, and should automatically open a
-browser window showing it.
+Which ever way you choose, you will now have a backend instance running on port 7007,
+and the frontend running on port 3000. A browser window should also automatically open,
+showing the frontend.
 
 ## Authentication
 

docs/tutorials/package-role-migration.md

@@ -116,7 +116,7 @@ The way to execute this step of the migration is not as well defined as the prev
 - In places where the entire repo is being built, use `yarn backstage-cli repo build`, which also supports the `--since` flag. The migration here is a bit more nuanced as it depends on why you are building all packages.
   - If you are building all packages to **verify** that you are able to build them, you most likely want `backstage-cli repo build --all`. The `--all` flag signals that bundled packages like `packages/app` and `packages/backend` should be built as well. Pair this up with a `--since` flag in CI to avoid needing to build all packages.
   - If you are building all packages to **publish** them, then `backstage-cli repo build` is enough, as it builds all published packages.
-  - If you are building all packages to **deploy** them, you likely don't want to use the `repo` command at all, simply call `yarn build` in the packages you want to deploy instead. For example, if you are deploying the backend with a docker host build, it's enough to call `yarn build` inside `packages/backend`.
+  - If you are building all packages to **deploy** them, you likely don't want to use the `repo` command at all, simply call `yarn build` in the packages you want to deploy instead. For example, if you are deploying the backend with a docker host build, it's enough to call `yarn build` inside `packages/backend`. In a standard `@backstage/create-app` there is also a shorthand for building the backend from the root, `yarn build:backend`.
 
 ## FAQ