Create a project

import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; import HeaderLabel from '@site/src/components/Docs/HeaderLabel'; import NextSteps from '@site/src/components/NextSteps'; import LangPartials from '@site/src/components/LangPartials';

With a workspace, we can now house one or many projects, with a project being an application, library, or more. In the end, each project will have its own build layer, personal tasks, and custom configuration.

Declaring a project in the workspace

Although a project may exist in your repository, it's not accessible from moon until it's been mapped in the projects setting found in .moon/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 application called "server", our projects setting would look like the following.

projects:
  client: 'apps/client'
  server: 'apps/server'

We can now run moon project client and moon project server to display information about each project. If these projects were not mapped, or were pointing to an invalid source, the command would throw an error.

:::success

The projects setting also supports a list of globs, if you'd prefer to not manually curate the projects list!

:::

Configuring a project

A project can be configured in 1 of 2 ways:

• Through the .moon/tasks/**/* config files, which defines file groups and tasks that are inherited by matching projects within the workspace. Perfect for standardizing common tasks like linting, typechecking, and code formatting.
• Through the <project>/moon.* config file, found at the root of each project, which defines files groups, tasks, dependencies, and more that are unique to that project.

Both config files are optional, and can be used separately or together, the choice is yours!

Now let's continue with our client and server example above. If we wanted to configure both projects, and define config that's also shared between the 2, we could do something like the following:

<Tabs groupId="project-config" defaultValue="client" values={[ { label: 'Client', value: 'client' }, { label: 'Server', value: 'server' }, { label: 'Both (inherited)', value: 'inherit' }, ]}

tasks:
  build:
    command: 'vite dev'
    inputs:
      - 'src/**/*'
    outputs:
      - 'dist'

tasks:
  build:
    command: 'babel src --out-dir build'
    inputs:
      - 'src/**/*'
    outputs:
      - 'build'

tasks:
  format:
    command: 'prettier --check .'
  lint:
    command: 'eslint --no-error-on-unmatched-pattern .'
  test:
    command: 'jest --passWithNoTests .'
  typecheck:
    command: 'tsc --build'

Adding optional metadata

When utilizing moon in a large monorepo or organization, ownership becomes very important, but also difficult to maintain. To combat this problem, moon supports the project field within a project's moon.* config.

This field is optional by default, but when defined it provides metadata about the project, specifically around team ownership, which developers maintain the project, where to discuss it, and more!

Furthermore, we also support the layer and language settings for a more granular breakdown of what exists in the repository.

layer: 'tool'
language: 'typescript'

project:
  name: 'moon'
  description: 'A repo management tool.'
  channel: '#moon'
  owner: 'infra.platform'
  maintainers: ['miles.johnson']

Next steps

<NextSteps links={[ { icon: 'toolchain', label: 'Setup toolchain', url: './setup-toolchain' }, { icon: 'workspace-config', label: ( <span> Configure <code>.moon/workspace.</code> further </span> ), url: './config/workspace', }, { icon: 'project-config-global', label: ( <span> Configure <code>.moon/tasks/**/</code> further </span> ), url: './config/tasks', }, { icon: 'project-config', label: ( <span> Configure <code>moon.*</code> further </span> ), url: './config/project', }, { icon: 'project', label: 'Learn about projects', url: './concepts/project' }, ]} />