> ## Documentation Index > Fetch the complete documentation index at: https://docs.qlty.sh/llms.txt > Use this file to discover all available pages before exploring further. # Components > Group a project's files by path to see code coverage per service, package, or team, with no changes to your CI setup. Components group the files in a project by path, so you can see coverage for each service, package, or team inside one repository. You define components in Qlty Cloud, not in CI, so you can add or change them at any time without touching your coverage uploads. Qlty already aggregates coverage by directory in the [Code view](/cloud/projects/code), so when each service lives in its own top-level directory you can see its coverage there without any setup. Components are for groupings that do not follow the directory tree: a team that owns several services spread across a monorepo, a shared library plus the places that use it, or all the files matched by one entry in a `CODEOWNERS` file. ## Components or coverage tags? Both features break coverage down into smaller pieces, but they work differently: | | Components | [Coverage tags](/coverage/tags) | | - | - | - | | Groups coverage by | File path | Coverage report (for example, one tag per test suite) | | Created by | Users, in project settings or through the API | CI, automatically, the first time a report is published with the tag | | Changed by | Editing the component's path patterns in Qlty | Editing the uploads in your CI configuration | | Commit statuses | None | One set per tag | | When a commit has no data | No carry forward | Its most recent report is carried forward from an earlier commit | | Effect of a stale entry | A component whose patterns match no files shows no coverage | A tag that no longer receives reports is still carried forward until deleted | Start with components. They need no CI changes, and you can adjust them as your codebase changes. Use coverage tags when your CI runs test suites selectively, for example a monorepo that only runs the tests for the service that changed. In that setup, Qlty needs tags to [carry forward](/coverage/carry-forward-tags) coverage for the suites that did not run. Tags and components can be used together. ## Enabling components Components are enabled per project. You need admin access to the project. 1. Open the project and go to *Project Settings > Features*. 2. Under **Analytics**, turn on **Components**. Once enabled, a **Components** tab appears in the project navigation. ## Defining a component 1. Go to *Project Settings > Components*. 2. Click **Create Component**. 3. Fill in the component details and save. | Field | Required | Details | | - | - | - | | **Name** | Yes | Up to 100 characters. Give each component a unique name, for example `Frontend` or `Billing`. | | **Description** | No | A note on what the component represents. | | **Path Patterns** | Yes | One or more patterns that select the component's files. Enter one per line, or separate them with commas. | The components list in *Project Settings > Components* shows a **Files** count for each component: the number of files on the default branch that its patterns match. Use it to confirm that your patterns select the files you expect. From the same list you can edit, duplicate, or delete a component. ## Path patterns Each pattern is matched against a file's path relative to the root of the repository, for example `backend/api/users.py`. These are the same paths that appear in your coverage reports after [path fixing](/coverage/path-fixing). A file belongs to a component when it matches at least one of the component's patterns. The rules are: * **A pattern must match the whole path.** `backend` on its own matches nothing inside the `backend/` directory. Use `backend/*`. * **A star matches any characters, including slashes.** `*` is not limited to one directory level: `backend/*` matches every file under `backend/` at any depth, and `backend/*.py` matches both `backend/app.py` and `backend/api/users.py`. * **A double star behaves the same as a single star.** `backend/**` and `backend/*` select the same files. * **Every other character is literal.** `?`, `[abc]`, `{a,b}`, and `!` have no special meaning. To cover several directories, add one pattern for each. | Pattern | Matches | Does not match | | - | - | - | | `backend/*` | `backend/app.py`, `backend/api/users.py` | `frontend/src/index.ts` | | `backend/*.py` | `backend/app.py`, `backend/api/users.py` | `backend/README.md` | | `backend/**/*.py` | `backend/api/users.py` | `backend/app.py` | | `*.test.ts` | `app.test.ts`, `web/src/utils/date.test.ts` | `web/src/utils/date.ts` | | `packages/ui/*` | `packages/ui/src/Button.tsx` | `packages/ui-kit/index.ts` | `backend/**/*.py` requires at least one directory between `backend/` and the file, so it skips files directly inside `backend/`. To select every Python file under `backend/`, use `backend/*.py`. Components do not have to cover the whole repository, and they can overlap: * A file that matches no component is left out of every component. It still counts toward the project's total coverage. * A file that matches several components counts toward each of them. ### Example: components by owning team A monorepo where each team owns a few services and packages, in directories that are not grouped by team: | Component | Path patterns | | - | - | | `Payments` | `services/billing/*`, `services/invoicing/*`, `packages/money/*` | | `Growth` | `services/onboarding/*`, `apps/web/src/signup/*` | | `Platform` | `services/gateway/*`, `packages/auth/*`, `infra/*` | Each team's component rolls up coverage across everything it owns, which no single directory in the Code view would show. ## Where component coverage appears ### Components tab The project's **Components** tab lists every component with its metrics on the default branch: files, lines of code, maintainability, complexity, duplication, coverage, and issues. Click a component to see its files with per-file coverage. ### Pull request coverage On a pull request's [Coverage tab](/cloud/projects/pull-requests#coverage-tab), the **Components** sub-view lists each component that contains a file changed by the pull request. For each one it shows the coverage rating on the base and the head, the coverage percentage on the head, and the change between the two. This view compares against the pull request's base, so it needs a coverage report for the base commit. It is empty when the pull request changes no files that belong to a component. ### Pull request comments The [coverage summary comment](/coverage/pull-request-comments) includes a **Modified Components** table. It lists the same components as the pull request's Components sub-view, with each component's coverage rating and its diff coverage: the coverage of the lines the pull request changed in that component. ### REST API The API returns the [latest metrics](/api-reference/metrics/get-component-metrics) and the [metric history](/api-reference/metrics/get-component-metric-series) for a component, including coverage. ## Changing a component When you edit a component's path patterns, the Components tab and pull request views use the new definition right away. Metric history is different. Qlty records each component's coverage when a coverage report is processed, using the component's definition at that time. Editing a component does not recalculate the history that was already recorded. [Selective coverage](/coverage/selective-coverage) uploads do not contribute to component coverage. ## Managing components with the API Components can also be managed through the REST API. Teams use it to keep components in sync with a `CODEOWNERS` file, so each owner's component tracks the paths the file assigns to them: * [List components](/api-reference/components/list-components) * [Create component](/api-reference/components/create-component) * [Update component](/api-reference/components/update-component) * [Delete component](/api-reference/components/delete-component) In the API, `pathGlobs` is an array with one pattern per entry. Components must be enabled for the project before they can be created or changed through the API. ## See Also * [Coverage Tags](/coverage/tags) - Break coverage down by coverage report * [Carry Forward Tags](/coverage/carry-forward-tags) - Complete coverage when CI runs test suites selectively * [Browsing Coverage](/coverage/browsing) - Other ways to explore coverage data * [Monorepos](/monorepos) - Using Qlty in a monorepo This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.