docs: Rename ID to name. (moonrepo#219)

Rename ID to name.

README.md

@@ -24,7 +24,7 @@ and provide a first-class developer experience.
   _not_ an "all at once adoption". Migrate project-by-project, or task-by-task, it's up to you!
 - **Reduced scripts confusion** - `package.json` scripts can become unwieldy, very quickly. No more
   duplicating the same script into every package, or reverse-engineering which root scripts to use.
-  With moon, all you need to know is the project ID, and a task ID.
+  With moon, all you need to know is the project name, and a task name.
 - **Ensure correct versions** - Whether it's Node.js or npm, ensure the same version of each tool is
   the same across _every_ developer's environment. No more wasted hours of debugging.
 - **Automation built-in** - When applicable, moon will automatically install `node_modules`, or sync

packages/cli/README.md

@@ -51,7 +51,7 @@ and provide a first-class developer experience.
   _not_ an "all at once adoption". Migrate project-by-project, or task-by-task, it's up to you!
 - **Reduced scripts confusion** - `package.json` scripts can become unwieldy, very quickly. No more
   duplicating the same script into every package, or reverse-engineering which root scripts to use.
-  With moon, all you need to know is the project ID, and a task ID.
+  With moon, all you need to know is the project name, and a task name.
 - **Ensure correct versions** - Whether it's Node.js or npm, ensure the same version of each tool is
   the same across _every_ developer's environment. No more wasted hours of debugging.
 - **Automation built-in** - When applicable, moon will automatically install `node_modules`, or sync

website/docs/commands/migrate/from-package-json.mdx

@@ -11,7 +11,7 @@ to our [`project.yml`](../../config/project) format. When ran, the following cha
 - Updates `package.json` by removing all converted scripts. If all scripts were converted, the
   entire block is removed.
 - Links `package.json` dependencies as `project.yml` [dependencies](../../config/project#dependson)
-  (`dependsOn`). Will map a package's name to their moon project ID.
+  (`dependsOn`). Will map a package's name to their moon project name.
 
 This command is ran _per project_, and for this to operate correctly, requires all
 [projects to be configured in the workspace](../../config/workspace#projects). There's also a
@@ -32,7 +32,7 @@ won't run builds that should be. Be sure to audit each task after migration!
 
 ### Arguments
 
-- `<project>` - ID of a project, as defined in [`projects`](../../config/workspace#projects).
+- `<project>` - Name of a project, as defined in [`projects`](../../config/workspace#projects).
 
 ## Caveats
 

website/docs/commands/project-graph.mdx

@@ -2,7 +2,7 @@
 title: project-graph
 ---
 
-The `moon project-graph [id]` command will generate a graph of all configured projects, with edges
+The `moon project-graph [name]` command will generate a graph of all configured projects, with edges
 between dependencies, and will output the graph in
 [Graphviz DOT format](https://graphviz.org/doc/info/lang.html). This output can then be used by any
 tool or program that supports DOT, for example, this
@@ -14,12 +14,12 @@ In the future we aim to replace this with an interactive visualizer.
 $ moon project-graph > graph.dot
 ```
 
-> A project ID can be passed to focus the graph to only that project and it's dependencies. For
+> A project name can be passed to focus the graph to only that project and it's dependencies. For
 > example, `moon project-graph app`.
 
 ### Arguments
 
-- `[id]` - Optional ID of a project to focus, as defined in
+- `[name]` - Optional name of a project to focus, as defined in
   [`projects`](../config/workspace#projects).
 
 ## Example output

website/docs/commands/project.mdx

@@ -2,17 +2,17 @@
 title: project
 ---
 
-The `moon project <id>` command will display all available information about a project that has been
-configured and exists within the graph. If a project does not exist, the program will return with a
-1 exit code.
+The `moon project <name>` command will display all available information about a project that has
+been configured and exists within the graph. If a project does not exist, the program will return
+with a 1 exit code.
 
 ```shell
 $ moon project web
 ```
 
 ### Arguments
 
-- `<id>` - ID of a project, as defined in [`projects`](../config/workspace#projects).
+- `<name>` - Name of a project, as defined in [`projects`](../config/workspace#projects).
 
 ### Options
 

website/docs/commands/query/projects.mdx

@@ -30,7 +30,7 @@ This will return a list of project objects with the following structure:
 
 All values are case-insensitive regex patterns.
 
-- `--id <regex>` - Filter projects that match this ID.
+- `--id <regex>` - Filter projects that match this ID/name.
 - `--language <regex>` - Filter projects of this programming language.
 - `--source <regex>` - Filter projects that match this source path.
 - `--tasks <regex>` - Filter projects that have the following tasks.

website/docs/commands/run.mdx

@@ -24,7 +24,7 @@ $ moon run :lint
 
 ### Options
 
-- `--dependents` - Run downstream dependent targets (of the same task ID) as well.
+- `--dependents` - Run downstream dependent targets (of the same task name) as well.
 - `--profile <type>` - Record and [generate a profile](../guides/profile) for ran tasks.
   - Types: `cpu`, `heap`
 

website/docs/concepts/project.mdx

@@ -6,18 +6,18 @@ A project is a library, application, package, binary, tool, etc, that contains s
 files, assets, resources, and more. A project must exist and be configured within a
 [workspace](./workspace).
 
-## ID
+## Names
 
-A project identifier is a unique resource for locating a project. The ID is explicitly configured
-within [`.moon/workspace.yml`](../config/workspace), as a key within the
+A project name (or identifier) is a unique resource for locating a project. The name is explicitly
+configured within [`.moon/workspace.yml`](../config/workspace), as a key within the
 [`projects`](../config/workspace#projects) setting, and can be written in camel/kebab/snake case.
-IDs support `a-z`, `A-Z`, `0-9`, `_`, `-`, and must start with a character.
+Names support `a-z`, `A-Z`, `0-9`, `_`, `-`, and must start with a character.
 
-IDs are used heavily by configuration and the command line to link and reference everything. They're
-also a much easier concept for remembering projects than file system paths, and they typically can
-be written with less key strokes.
+Names are used heavily by configuration and the command line to link and reference everything.
+They're also a much easier concept for remembering projects than file system paths, and they
+typically can be written with less key strokes.
 
-Lastly, a project ID can be paired with a task ID to create a [target](./target).
+Lastly, a project name can be paired with a task name to create a [target](./target).
 
 ## Configuration
 

website/docs/concepts/target.mdx

@@ -3,7 +3,7 @@ title: Targets
 ---
 
 A target is an identifier that pairs a [project](./project) to one of its [tasks](./task), in the
-format of `project_id:task_id`.
+format of `project_name:task_name`.
 
 Targets are used by terminal commands...
 
@@ -23,7 +23,7 @@ tasks:
 
 ## Project scopes
 
-While a target typically pairs project and task IDs, we also support advanced targets through a
+While a target typically pairs project and task names, we also support advanced targets through a
 concept known as project scopes. Scopes allow us to easily define targets with external or many
 sources, but _are not available in all contexts_.
 
@@ -77,9 +77,9 @@ tasks:
 > Only available when configuring a task.
 
 When referring to another task within the current project, you can utilize the `~` scope, which will
-be expanded to the current project's identifier. This is useful for situations where the identifier
-is unknown, for example, when configuring [`.moon/project.yml`](../config/global-project). Or if you
-just want a shortcut!
+be expanded to the current project's name. This is useful for situations where the name is unknown,
+for example, when configuring [`.moon/project.yml`](../config/global-project). Or if you just want a
+shortcut!
 
 ```yaml title=".moon/project.yml"
 # Configured as

website/docs/concepts/task.mdx

@@ -6,13 +6,14 @@ Tasks are commands that are ran in the context of a [project](./project). Undern
 task is simply an npm binary or a system command that is ran as a child process. Tasks are processed
 in a parallel thread pool within moon's orchestration layer.
 
-## ID
+## Names
 
-A task identifier is a unique resource for locating a task _within_ a project. The ID is explicitly
-configured as a key within the [`tasks`](../config/project#tasks) setting, and can be written in
-camel/kebab/snake case. IDs support `a-z`, `A-Z`, `0-9`, `_`, `-`, and must start with a character.
+A task name (or identifier) is a unique resource for locating a task _within_ a project. The name is
+explicitly configured as a key within the [`tasks`](../config/project#tasks) setting, and can be
+written in camel/kebab/snake case. Names support `a-z`, `A-Z`, `0-9`, `_`, `-`, and must start with
+a character.
 
-A task ID can be paired with a project ID to create a [target](./target).
+A task name can be paired with a project name to create a [target](./target).
 
 ## Configuration
 

website/docs/concepts/token.mdx

@@ -325,7 +325,7 @@ tasks:
 
 ### `$project`
 
-ID of the project that owns the currently running task, as defined in
+ID/name of the project that owns the currently running task, as defined in
 [`.moon/workspace.yml`](../config/workspace).
 
 ```yaml
@@ -411,7 +411,7 @@ tasks:
 
 ### `$target`
 
-Target that is currently running. Is a combination of project and task IDs.
+Target that is currently running. Is a combination of project and task name.
 
 ```yaml
 # Configured as
@@ -430,7 +430,7 @@ tasks:
 
 ### `$task`
 
-ID of the task that is currently running.
+ID/name of the task that is currently running.
 
 ```yaml
 # Configured as

website/docs/config/project.mdx

@@ -18,7 +18,7 @@ task graphs. The most common use case for this is building those projects _befor
 one, and for syncing [`package.json`](../concepts/project#packagejson) dependencies and
 [`tsconfig.json`](../concepts/project#tsconfigjson) project references when applicable.
 
-When defined, this setting requires an array of project IDs, which are the keys found in the
+When defined, this setting requires an array of project names, which are the keys found in the
 [`projects`](./workspace#projects) map.
 
 ```yaml title="project.yml"
@@ -128,7 +128,7 @@ Can be a name, email, LDAP name, GitHub username, etc, the choice is yours.
 
 > `string`
 
-A human readable name of the project. This is _different_ from the unique project ID configured in
+A human readable name of the project. This is _different_ from the unique project name configured in
 [`projects`](./workspace#projects).
 
 ### `owner`
@@ -143,8 +143,8 @@ suggest _not_ listing people/developers as the owner, use [maintainers](#maintai
 > `Record<string, TaskConfig>`
 
 Tasks are actions that are ran within the context of a [project](../concepts/project), and commonly
-wrap an npm binary or system command. This setting requires a map, where the key is a unique
-identifier for the task, and the value is an object of task parameters.
+wrap an npm binary or system command. This setting requires a map, where the key is a unique name
+for the task, and the value is an object of task parameters.
 
 ```yaml title="project.yml"
 tasks:
@@ -446,7 +446,7 @@ Provides a layer of control when inheriting tasks from [`.moon/project.yml`](./g
 #### `exclude`
 
 The optional `exclude` setting permits a project to exclude specific tasks from being inherited. It
-accepts a list of strings, where each string is the ID of a global task to exclude.
+accepts a list of strings, where each string is the name of a global task to exclude.
 
 ```yaml title="project.yml" {4}
 workspace:
@@ -460,7 +460,7 @@ workspace:
 #### `include`
 
 The optional `include` setting permits a project to _only_ include specific inherited tasks (works
-like an allow/white list). It accepts a list of strings, where each string is the ID of a global
+like an allow/white list). It accepts a list of strings, where each string is the name of a global
 task to include.
 
 When this field is not defined, the project will inherit all tasks from the global project config.
@@ -482,8 +482,8 @@ workspace:
 #### `rename`
 
 The optional `rename` setting permits a project to rename the inherited task within the current
-project. It accepts a map of strings, where the key is the original ID (found in the global project
-config), and the value is the new ID to use.
+project. It accepts a map of strings, where the key is the original name (found in the global
+project config), and the value is the new name to use.
 
 For example, say we have 2 tasks in the global project config called `buildPackage` and
 `buildApplication`, but we only need 1, and since we're an application, we should omit and rename.

website/docs/config/workspace.mdx

@@ -103,9 +103,9 @@ manual map of projects (default), _or_ a list of globs in which to automatically
 <TabItem value="manual">
 
 When using a map, each project must be _manually_ configured and requires a unique
-[ID](../concepts/project#id) as the map key, where this ID is used heavily on the command line and
-within the project graph for uniquely identifying the project amongst all projects. The map value
-(known as the project source) is a file system path to the project folder, relative from the
+[name](../concepts/project#names) as the map key, where this name is used heavily on the command
+line and within the project graph for uniquely identifying the project amongst all projects. The map
+value (known as the project source) is a file system path to the project folder, relative from the
 workspace root, and must be contained within the workspace boundary.
 
 ```yaml title=".moon/workspace.yml"
@@ -123,10 +123,10 @@ If manually mapping projects is too tedious or cumbersome, you may provide a lis
 [globs](../concepts/file-pattern#globs) to automatically locate all project folders, relative from
 the workspace root.
 
-When using this approach, the project ID is derived from the project folder name, and is cleaned to
-our [supported characters](../concepts/project#id) . Furthermore, globbing **does risk the chance of
-collision**, and when that happens, we log a warning and skip the conflicting project from being
-configured in the project graph.
+When using this approach, the project name is derived from the project folder name, and is cleaned
+to our [supported characters](../concepts/project#names) . Furthermore, globbing **does risk the
+chance of collision**, and when that happens, we log a warning and skip the conflicting project from
+being configured in the project graph.
 
 ```yaml title=".moon/workspace.yml"
 projects:

website/docs/create-project.mdx

@@ -17,8 +17,8 @@ build layer, personal tasks, and custom configuration.
 
 Although a project may exist in your repository, it's not accessible from moon until it's been
 mapped in the [`projects`](./config/workspace#projects) setting found in
-[`.moon/workspace.yml`](./config/workspace). When mapping a project, we require a unique identifier
-for the project, and a project source location (path relative from the workspace root).
+[`.moon/workspace.yml`](./config/workspace). When mapping a project, we require a unique name for
+the project, and a project source location (path relative from the workspace root).
 
 Let's say we have a frontend web application called "client", and a backend Node.js application
 called "server", our `projects` setting would look like the following.

website/docs/faq.mdx

@@ -32,9 +32,8 @@ project, and provides us with the following:
 - The configuration is language agnostic. All projects are configured in a similar manner.
 - Tasks can reference other tasks easily. For example, npm scripts referencing rake tasks, and vice
   verse, is a non-ideal experience.
-- Dependencies defined with [`dependsOn`](./config/project#dependson) use moon project identifiers,
-  and not language specific semantics. This field also easily populates the dependency/project
-  graphs.
+- Dependencies defined with [`dependsOn`](./config/project#dependson) use moon project names, and
+  not language specific semantics. This field also easily populates the dependency/project graphs.
 - For JavaScript projects:
   - `package.json` dependencies (via `dependsOn`) are kept in sync when
     [`node.syncProjectWorkspaceDependencies`](./config/workspace#syncprojectworkspacedependencies)

website/docs/intro.mdx

@@ -25,7 +25,7 @@ and provide a first-class developer experience.
   _not_ an "all at once adoption". Migrate project-by-project, or task-by-task, it's up to you!
 - **Reduced scripts confusion** - `package.json` scripts can become unwieldy, very quickly. No more
   duplicating the same script into every package, or reverse-engineering which root scripts to use.
-  With moon, all you need to know is the project ID, and a task ID.
+  With moon, all you need to know is the project name, and a task name.
 - **Ensure correct versions** - Whether it's Node.js or npm, ensure the same version of each tool is
   the same across _every_ developer's environment. No more wasted hours of debugging.
 - **Automation built-in** - When applicable, moon will automatically install `node_modules`, or

website/docs/run-task.mdx

@@ -11,7 +11,7 @@ import NextSteps from '@site/src/components/NextSteps';
 
 Even though we've [created a task](./create-task), it's not useful unless we _run it_, which is done
 with the [`moon run <target>`](./commands/run) command. This command requires a single argument, a
-[primary target](./concepts/target), which is the pairing of a project ID and task ID. In the
+[primary target](./concepts/target), which is the pairing of a project name and task name. In the
 example below, our project is `app`, the task is `typecheck`, and the target is `app:typecheck`.
 
 ```shell
@@ -36,7 +36,7 @@ primary target, as their outputs may be required for the primary target to funct
 However, if you're working on a project that is shared and consumed by other projects, you may want
 to verify that downstream dependents have not been indirectly broken by any changes. This can be
 achieved by passing the `--dependents` option, which will run dependent targets (of the same task
-ID) _after_ the primary target.
+name) _after_ the primary target.
 
 ```shell
 $ moon run app:typecheck --dependents