Support and versioning
Druxt follows semantic versioning on a held stack: what the current 0.x releases promise, where 1.0.0 and 2.0.0 are headed, and how an API leaves the framework.
Druxt follows semantic versioning. This page states what that covers today: the stack the current releases support and what a release may change, then how an API leaves the framework.
The supported stack
The full compatibility table, with the known pins and workarounds, lives
with the druxt module reference. The short version:
| Layer | Supported |
|---|---|
| Nuxt | 2.15 or later, Nuxt 2 line only |
| Vue | 2.7 |
| Node | 16, the tested version |
| Drupal core | 10.1 through 11 |
Nuxt 2, Vue 2 and Node 16 are past their upstream end of life. The current line exists to give sites built on this stack a stable, maintained base. Support for Nuxt 4 will arrive in the 2.0.x release, and the stack above does not change before then.
The current line
Druxt is on its 0.x line. Every druxt* package moves together in a
release, so a site upgrades them as one set, with the commands in
Upgrade a Druxt site. A minor release can change
behaviour, and its changelog says so. Anything removed is deprecated
first.
Where it goes next
1.0.0 and 2.0.x are planned and have no dates.
- 1.0.0 declares this line stable on the same stack. Moving to it from the last 0.x release is a version bump with no breaking changes, and fixes keep landing on the 1.x line for a while after.
- 2.0.x brings Nuxt 4 and Vue 3 support, published as
@druxt/*packages. Everything deprecated before it is removed there.
How deprecation works
A deprecated API logs a console warning at runtime naming its replacement and linking a ledger entry, like this one:
[druxt] The `hash` argument for `druxt/addResource` has been deprecated,
see https://druxtjs.org/modules/druxt/deprecations#druxtstore-addresource-hashEach deprecation has a ledger entry stating what changed, the replacement, and the removal version, in the package that owns it:
A quiet console in development means nothing on the removal list applies to your site.
Security
Report vulnerabilities privately through GitHub security advisories; do not open a public issue for them. The policy, response time and supported-versions statement live in the repository's SECURITY.md.