單一存儲庫

A guide to setting up Master CSS in a modern repository.

Foreword

The Language Service and code linting both support the monorepo.

By default, language server forms independent workspaces from project CSS entries that import @master/css, entries that use the lightweight @master entry; marker, or package.json files that declare Master CSS package dependencies, independent of the package manager's workspace. The same goes for ESLint, which forms a new working directory based on the location of its configuration file.

Officially integrated packages or extensions automatically read the project CSS entry based on the current running directory. This means that you can start using it with zero setup as long as you create a marked CSS entry in the workspace, or declare a Master CSS dependency in that workspace's package.json when using the bundled preset.

One project, one workspace

Inside one package.json project, Master CSS supports one workspace instance. That workspace has one project manifest graph, one source-scanning context, and one set of tool integrations for the current project boundary.

Master CSS does not split a single package project into separate utility workspaces from multiple static rendering outputs. For example, do not model one package as independent admin.css and shop.css scanning areas and expect the language service, ESLint, and build integrations to treat them as separate Master CSS workspaces.

When different applications need cleanly separated static rendering, manifest loading, linting, and editor behavior, create separate projects in the monorepo. A typical structure is projects/admin and projects/shop, with each project owning its own package.json, CSS entry, and integration settings.

This creates separate project boundaries for projects/admin and projects/shop.

This keeps each application's generated CSS, source scanning, diagnostics, and editor state aligned with the same project root. Shared design tokens can still live at the repository root and be imported by each project workspace.

Share the project manifest source

In each workspace, import shared project CSS files and add workspace-specific definitions after them.

@import '@master/css';@import '../../index.css';@theme {    --color-primary: #4f46e5;}@components {    app-shell {        @compose min-h:100vh bg:surface-base;    }}

Later definitions in the workspace file can override root options, variables, tokens, utilities, and matching component buckets.

Keep multiple application static rendering targets inside one package project.

Give each application its own package project and Master CSS workspace.

Finally, using a monorepo and having multiple workspaces doesn't mean you have to create multiple configurations. In most cases, you just need one workspace entry.