Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
104 changes: 104 additions & 0 deletions docs/configuration/extends.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,104 @@
---
title: "extends"
date: 2024-06-06T00:00:00+00:00
anchor: "extends"
weight:
---

## Configuration

<div className="config-wrapper"><div className="config">__name__: extends</div>
<div className="config">__type__: array</div>
<div className="config">__default__: []</div></div>

```json showLineNumbers
{
"name": "company/project",
"extra": {
"violinist": {
// highlight-next-line
"extends": []
}
}
}
```

## Explanation

When you have many repositories that should behave the same way, copying the full Violinist configuration to every `composer.json` quickly becomes hard to maintain. The `extends` option lets you centralise your shared settings in one or more remote JSON documents and ask Violinist to import them before applying the project specific overrides that live in the repository.
Copy link

Copilot AI Apr 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hyphenation: “project specific” should be “project-specific” when used as a compound modifier.

Suggested change
When you have many repositories that should behave the same way, copying the full Violinist configuration to every `composer.json` quickly becomes hard to maintain. The `extends` option lets you centralise your shared settings in one or more remote JSON documents and ask Violinist to import them before applying the project specific overrides that live in the repository.
When you have many repositories that should behave the same way, copying the full Violinist configuration to every `composer.json` quickly becomes hard to maintain. The `extends` option lets you centralise your shared settings in one or more remote JSON documents and ask Violinist to import them before applying the project-specific overrides that live in the repository.

Copilot uses AI. Check for mistakes.

Each entry in the array can either reference a Composer package that exposes a Violinist configuration file or point to a relative path inside the repository. Violinist will fetch the configuration snippets in the order you list them, merge the keys they contain, and finally apply whatever options are defined directly inside the local `extra.violinist` block. Later entries, including the local configuration, always override values defined earlier in the list, allowing every project to keep its unique tweaks while inheriting the defaults that come from your shared templates.

Comment on lines +30 to +31
Copy link

Copilot AI Apr 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The description of what a Composer package provides is internally inconsistent: here it says the package exposes a “Violinist configuration file”, but later the doc says Violinist reads the dependency’s extra.violinist block from its composer.json. Please align the wording and (if applicable) document the expected file name/path vs composer.json semantics explicitly so users know what to publish.

Copilot uses AI. Check for mistakes.
Because extended configuration is resolved at run time, you can update a central document and have every repository inherit the change the next time Violinist runs. When you share configuration through a Composer package, each project still needs to receive an updated version of that package—usually by running an automated dependency update such as a Violinist pull request—before the new settings take effect. This keeps large organisations aligned without requiring the same change to be repeated in dozens of composer files.
Copy link

Copilot AI Apr 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wording: “run time” is typically written as “runtime” in this context.

Suggested change
Because extended configuration is resolved at run time, you can update a central document and have every repository inherit the change the next time Violinist runs. When you share configuration through a Composer package, each project still needs to receive an updated version of that package—usually by running an automated dependency update such as a Violinist pull request—before the new settings take effect. This keeps large organisations aligned without requiring the same change to be repeated in dozens of composer files.
Because extended configuration is resolved at runtime, you can update a central document and have every repository inherit the change the next time Violinist runs. When you share configuration through a Composer package, each project still needs to receive an updated version of that package—usually by running an automated dependency update such as a Violinist pull request—before the new settings take effect. This keeps large organisations aligned without requiring the same change to be repeated in dozens of composer files.

Copilot uses AI. Check for mistakes.

## Example

Imagine that your organisation has agreed on a default set of labels and automerge behaviour. You store those defaults in a small JSON file inside the repository at `.violinist/base.json`:

```json showLineNumbers
{
"labels": [
"dependencies",
"automated"
],
"automerge": 1,
"automerge_method": "squash"
}
```

Then each project can reference that shared configuration while still changing or extending whatever it needs:

```json showLineNumbers
{
"name": "company/project",
"extra": {
"violinist": {
// highlight-start
"extends": [
".violinist/base.json"
],
"labels": [
"dependencies",
"needs-release"
],
"automerge_method": "merge"
// highlight-end
}
}
}
```

In this example the project inherits the `automerge` value from the shared document, overrides the merge method to "merge", and adds an extra label next to the defaults that were defined globally.
Copy link

Copilot AI Apr 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sentence says the local config “adds an extra label next to the defaults”, but earlier the doc states later entries “always override values defined earlier”. Please clarify how merging works for array values like labels (replace vs append/union), and adjust the example/explanation to match the actual behavior.

Copilot uses AI. Check for mistakes.

If you publish a reusable configuration through a Composer package, you can point `extends` at the package name. Violinist will read the `extra.violinist` block from that dependency's `composer.json` and merge it before applying the local overrides:

```json showLineNumbers
{
"extra": {
"violinist": {
"extends": [
"acme/violinist-policies"
]
}
}
}
```

## Chaining multiple sources

If you have several layers of defaults you can add as many entries to `extends` as you need. For example, the first entry might reference a package that publishes a shared configuration, and the second entry could reference a file that lives within the current repository. Violinist will read each source in sequence and merge the configuration so that the most specific file wins for overlapping keys:

```json showLineNumbers
{
"extra": {
"violinist": {
"extends": [
"vendor/shared-violinist-config",
".violinist/team-overrides.json"
]
}
}
}
```

This approach lets you compose a final configuration from multiple reusable building blocks, keeping your Violinist setup tidy even as the number of monitored projects grows.