This project aims to help run Drupal projects on secure and high-quality Drupal dependencies.
CHECK OUT the mxr576/ddqg-composer-audit package that
extends composer audit command with advisories originating from the ^dev-no-[a-zA-Z]+-versions$ releases.
Releases of this package that matches the ^dev-no-[a-zA-Z]+-versions$ regex ensure that your project
doesn't have installed dependencies with known quality problems.
$ composer require --dev mxr576/ddqg:[dev-no-insecure-versions|dev-no-unsupported-versions|dev-non-d10-compatible-versions]dev-no-insecure-versions: Project releases (versions) affected by public security advisories (PSAs), only in currently supported branches of a project.dev-no-deprecated-versions:- Projects flagged with Obsolete development status by maintainers
dev-no-unsupported-versions: This was inspired by this thread and it is a list of:- Projects flagged with Unsupported maintenance status by maintainers
- Project releases (versions) from unsupported branches
- Project releases that are not covered by the Drupal Security Team
dev-non-d10-compatible-versions: For Drupal 9 projects only, prevents installation of package versions that are not Drupal 10 compatible. It can make the Drupal 10 upgrade more painless.- Warning: This is only ~99% accurate because core compatibility information sometimes cannot be identified from the information available on Update Status API. compatible. See Github Actions logs for skipped projects/versions.
- [PLANNED] An opinionated list of projects that should be avoided
Should you depend on both dev-no-insecure-versions and dev-no-unsupported-versions and at the same time?
YES, you should. The dev-no-insecure-versions only contains version ranges affected by a PSA if they are in a
supported branch by maintainers. When a branch becomes unsupported, related version ranges disappear from this list.
The reasoning behind this implementation is that if a branch is not supported by maintainers (neither covered Drupal
Security Team) then your biggest problem is not depending on a version that has known PSA (which may or may not be
leveraged on your project) but the fact that your project depends on an unsupported version.
- Ignore releases with Drupal 7 compatibility as there is no plan to support Drupal 7