dbt/client-fake

dbt/client-fake 4.0.0 appears usable and reasonably transparent: it is MIT-licensed, has a substantial README, packaged tests, a complete source tree, no install-time lifecycle scripts, and an active, non-archived repository with a recent stable release. The main concern is maintenance continuity: the repository records no commits and no active maintainers in the last 3 months despite the recent release and push, while the project has minimal adoption and lacks security-policy and explicit workflow token-permission hardening. These are meaningful but not disqualifying concerns for a small testing utility, so dependency adoption is reasonable with normal review and monitoring.

Latest 4.0.0

Packagist

72%

Total Score

Maintainer Stability

Dependencies

100

Maturity

Supply Chain

Health Score Breakdown

Repo commit activity

The repository records zero commits and zero active maintainers in the last 3 months, which is a genuine maintenance-continuity concern. The recent release and repository push partly compensate, but they do not demonstrate sustained day-to-day activity.

Repo popularity

The repository has zero stars and forks and one watcher, showing very limited visible adoption. Popularity is supporting evidence rather than a verdict, so this modestly lowers confidence in ecosystem maturity but is not by itself a dependency blocker.

Repo tooling

Composer build tooling is present, but no security scanning tools are detected. Build reproducibility is supported, while security-process transparency remains a hygiene gap for a package distributed to consumers.

Security policy

The repository has no SECURITY.md or equivalent security policy. For a small testing utility this is a transparency gap rather than a severe adoption risk, but it leaves vulnerability-reporting expectations unclear.

Token permissions

The only workflow lacks top-level token permissions, with no explicit read-only declaration detected. Although no write permissions or dangerous workflow patterns were observed, explicit least-privilege configuration would provide stronger CI hardening.