Pull Requests

Pull Requests (PRs) are a fantastic way to contribute back to the project. It's one of the fastest ways to see a bug fix or new feature you care about land in the platform.

Choosing What to Implement

We welcome PRs for any open Issue. Issues labeled "Good First Issue" are typically easier to resolve for those who haven't contributed to the codebase before, and are therefore a great starting point.

If you're planning on implementing a bigger feature that doesn't have an issue attached yet, please reach out to our core team ahead of time to discuss.

Copyright License Agreement (CLA)

All code contributors are required to sign the Contributor License Agreement (CLA). When you start a pull request, a GitHub Action will prompt you to review the CLA and sign it by adding your name to contributors.yml. To clarify the intellectual property rights in the project and any Contributions, Directus requires that You accept the Contributor License Agreement. This license is for your protection as a contributor as well as the protection of Directus, recipients of software distributed or made available by Directus, and other contributors; it does not change your rights to use your own Contributions for any other purpose.

Changesets

To properly generate changelogs and determine the right version number after a change is merged, we rely on changesets. Each pull request should include a changeset that describes whether the change is a patch/minor/major version bump, and describe what the change is. Changesets should be written in past tense.

A changeset can be generated via the following command:

pnpm changeset

Changeset Bump Definitions

The following are the types of version bumps that can be specified in a changeset:

• Major (x.0.0) - A change has been made that is incompatible with previous versions.
• Minor (0.x.0) - A feature has been added that is backwards compatible with previous versions.
• Patch (0.0.x) - A bug has been fixed that is backwards compatible with previous versions.

Notices

Use a notice for changes that deserve extra visibility in the release notes, such as deprecations, required migrations, or behavior changes that users upgrading and/or extension authors should be aware of.

Add a ::: notice block at the end of the changeset body:

---
"@directus/app": minor
---

Deprecated the `VResizeable` component

::: notice

- Deprecation for extensions: The globally registered `VResizeable` component has been deprecated. Extension authors should migrate to `@directus/vue-split-panel` or provide their own implementation.

:::

The notice is extracted and displayed in the Potential Breaking Changes section at the top of the release notes. The rest of the changeset remains in its normal category.

Notices always appear under Potential Breaking Changes, regardless of whether the changeset is a major, minor, or patch release. Adding a notice does not affect the version bump. Choose the bump type based on the impact of the change, and add a notice whenever the change warrants additional attention.

Notice detection is strict. If the syntax does not match exactly, the notice will not be extracted.

To ensure your notice is recognized:

• Start the block with exactly ::: notice: all lowercase, with a single space between ::: and notice.
• End the block with ::: on its own line.
• Do not indent the opening or closing markers, or include trailing whitespace.
• Include some content between the markers. An empty block is not detected.
• Include exactly one notice block per changeset. Multiple notce blocks will result in a malformed output