npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2026 – Pkg Stats / Ryan Hefner

@docccs/cli

v1.3.0

Published

Keep Docccs project documentation current after a deploy, and pull the development standards that apply to the project.

Readme

@docccs/cli

Keeps Docccs project documentation current without anyone having to remember to.

Stack facts rot fast. Across a portfolio of Craft, WordPress and Drupal projects that is hundreds of version numbers nobody wants to maintain by hand. Set a repo up once and every push to its default branch tells Docccs what the checkout proves: CMS and plugin versions, PHP, the database, DDEV or Lando settings, and where the repo lives.

Docccs never reads your repository. A handful of named files leave from the checkout (your machine or your CI runner), which is why this works for clients whose code Docccs cannot reach.

Set up a repo (once, about a minute)

npx @docccs/cli init

That signs you in if needed, finds the project's document (by its repository URL, or asks), runs a first sync, and adds the CI job for the repo's host:

| Host | What init does | | --- | --- | | GitLab.com or self-hosted GitLab | Appends a docccs:sync job to .gitlab-ci.yml (asks first) | | GitHub | Writes .github/workflows/docccs.yml | | Bitbucket | Writes bitbucket-pipelines.yml, or prints the step if you already have one | | Pantheon origin | Says so: Pantheon cannot run CI, so sync from a mirror or run docccs sync after deploys |

The CI job needs one variable, DOCCCS_TOKEN: a token with the stack:write scope. Set it once at the top, as a GitLab group variable (masked), a GitHub organization secret, or a Bitbucket workspace variable, and every repo under it is covered. Commit the CI file and .docccs.json; neither holds a secret.

What a sync changes

| Change | What happens | | --- | --- | | A version moves (CMS, PHP, database, a plugin already in the doc) | Applied, with a revision | | A blank field can be filled from the repo (repo URL, local URL, database) | Applied, with a revision | | Anything of a different kind: another CMS, a plugin added or removed, Lando becoming DDEV, a different repo URL | Staged for review in Docccs | | A version field someone wrote as a note ("5.10 on the upgrade branch; 4.15 on master") | Staged for review, never overwritten |

Only plugins the project requires itself (listed in composer.json) are ever proposed as new rows; the dependencies they pull in are not, so a curated Drupal module list stays curated. When a repo has both .ddev/config.yaml and .lando.yml, it warns and leaves local tooling alone rather than guessing which one is real.

Access notes, gotchas, deploy steps, environments and contacts are human-written and are never touched. On each plugin your purpose and premium notes survive, rows you added by hand are never removed, and a hand-typed "Google Cloud" is recognised as craftcms/google-cloud.

applied  3 updates to Blue Wheel:
  Craft CMS version: 5.10.1 -> 5.10.3
  CKEditor: 5.6.1 -> 5.7.0
  SEOmatic: 5.1.21 -> 5.2.0

for review  1 change needs a human:
  Added: Blitz 5.9.0

Review: https://docccs.app/documents/.../stack

If nothing moved it says so and writes nothing, so it is safe on every push.

In CI, it never breaks the build

A sync problem (no token, Docccs unreachable, no matching document) prints a warning and exits 0: the deploy already happened, and documentation is not a reason to go red. Pass --strict to fail instead. The job runs only on the default branch.

On your machine

docccs sync does the same from a checkout. On a branch other than the default it only reports what would change, because the document describes what ships; pass --any-branch if that branch really is what runs. --dry-run reports without writing anywhere.

What is sent

composer.lock and composer.json (from the root, or src/), .ddev/config.yaml, .lando.yml, and for WordPress that is not Composer-managed, wp-includes/version.php plus the name, version and description from each plugin's header. Nothing else. .env files are never read.

AI coding agents

npx @docccs/cli skill            # once per machine: Claude Code skill + Codex global AGENTS.md
npx @docccs/cli skill --project  # into this repo: .claude/skills/docccs/SKILL.md + AGENTS.md block

The skill has the agent run docccs status when it starts work in a repo. Before it finishes, it runs docccs sync if it changed stack files and no Docccs CI job exists, and updates the document (over MCP, or by telling you what to change) if it changed setup, environments, deploy steps or gotchas. It never runs login or init itself, and a Docccs error never fails the task. docccs status shows whether a CI job exists and which branch you are on.

Development standards

Docccs already knows this project's CMS, versions and plugin list, so it can serve the coding standards that apply to it. docccs rules sync writes them where an AI coding assistant will read them, along with an instruction to keep the Docccs document current when a change affects setup, deploys, environments or gotchas.

docccs rules sync     # write the standards into this checkout
docccs rules check    # exit 1 if the checkout is behind
docccs rules show     # print them to stdout

CLAUDE.md and AGENTS.md get a managed block. Only what is between the markers is replaced; anything you wrote outside them comes back byte for byte, and a file with no block yet just gets one appended. .cursor/rules/docccs.mdc is namespaced to Docccs so it is written whole. Running rules sync twice leaves no diff. Commit .docccs-rules.json.

Commands

| Command | What it does | | --- | --- | | docccs init | Sign in, find the document, sync, add the CI job | | docccs sync | Update the document from this checkout. --dry-run, --any-branch, --ci, --strict | | docccs skill | Teach AI coding agents to keep the doc current. --project for this repo | | docccs rules sync | Writes this project's standards into the checkout | | docccs rules check | Reports drift, exits 1 if the checkout is behind | | docccs rules show | Prints the resolved standards to stdout | | docccs link | Pick the document by hand, writing .docccs.json (only if init cannot match it) | | docccs login | Stores a token in ~/.docccs/config.json (mode 600) | | docccs status | Shows the current login, link, standards version, and whether a newer CLI is available |

Environment overrides: DOCCCS_URL, DOCCCS_TOKEN, DOCCCS_DOCUMENT_ID, DOCCCS_DEFAULT_BRANCH.

Requires Node 18+. No dependencies.