Kitab Laravel Package

Product Decisions This Supports

• Docs-as-code quality gate: Evaluate Kitab as a CI step that renders documentation and executes/document-checks code samples, so READMEs, guides, and API examples for internal PHP packages fail the build when they drift from the implementation.
• Build vs. buy for documentation testing: The package is small, low-activity, and has no dependent packages, so this is less an adoption decision and more an input to a build/buy call: fork or vendor a narrow tool versus writing a PHPUnit-based executable-docs harness in-house.
• Developer-experience roadmap: Supports decisions about investing in onboarding docs, SDK examples, and tutorial accuracy for PHP/Laravel libraries where incorrect code samples create support load. The 0.12 parser work on anonymous classes matters here: mocks, Laravel service providers, and test-style examples frequently use anonymous classes, and previously those snippets were the ones most likely to fail rendering.
• Documentation platform scope: Use it to test whether "executable documentation" is worth product investment for a developer-facing API, before committing to a commercial docs platform or a homegrown solution.
• Dependency policy: Serves as a concrete case for defining rules on low-activity packages, PHP-version support, semver discipline, and maintenance ownership in the engineering standards roadmap. Release 0.12 is a useful worked example: a minor version shipped a major upstream bump (nikic/php-parser 3.* → 4.*), which is a compatibility event for anyone pinning or forking.
• Use cases: Internal package READMEs with runnable examples, getting-started tutorials that must remain copy-paste correct, and API guides where prose and code snippets live in the same source — especially examples that define classes on the fly.

When to Consider This Package

Consider it when:

• Documentation contains executable PHP examples and the team wants a CI check that those examples and rendered docs stay synchronized with the code. Anonymous-class examples are now inside the supported parsing surface as of 0.12, which widens the set of realistic snippets that can be tested.
• The scope is internal tooling or developer-facing docs, not runtime application code, so a pinned, vendored dependency is acceptable.
• The team has PHP capacity to fork and maintain a small, low-activity package, or can isolate it behind a script/CI job that is easy to replace.
• A time-boxed spike is enough to validate whether documentation drift is a measurable problem worth solving.
• The repository/license can be audited and the tool runs on the team's PHP version in a container or isolated CI image. Note that 0.12's move to php-parser 4.* raises the effective PHP floor versus 3.* but does not by itself demonstrate PHP 8.x or current Laravel support — verify in a container before committing.

Look elsewhere when:

• The target is a production Laravel application or anything on a modern PHP/Laravel support matrix. Releases remain sporadic and the 0.12 changelog is narrow (a CI bot config, one parser feature, one dependency bump); compatibility with current PHP/Laravel is still unproven.
• The organization requires active maintainers, security patching, or vendor support. With a small star count and zero dependents, there is no ecosystem safety net, and 0.12 does not change that picture — the release contains no maintenance or support commitments.
• Documentation is prose-first with few runnable examples, or the team already has a working PHPUnit/static-analysis-based approach.
• The decision requires a long-term platform commitment. Low release cadence makes this a maintenance liability rather than a strategic dependency.
• There is no appetite to own a fork or absorb upgrade work when PHP, CI environments, or the underlying parser change. The 3.→4. bump inside a minor release is exactly the kind of change a fork owner absorbs.

How to Pitch It (Stakeholders)

To executives: This is a low-cost, time-boxed experiment in documentation quality, not a platform investment. Kitab tests whether the code examples in our developer docs actually work, which reduces support tickets and onboarding friction for PHP/Laravel consumers. The latest release, 0.12, is incremental — better parsing for anonymous classes plus a supporting-library upgrade — so it improves the tool's coverage of realistic examples without changing the risk profile. The caveat is still material: release cadence is low and there are no downstream dependents, so this carries maintenance and compatibility risk. Recommend a small proof of concept in CI, with no placement on a critical path and a pre-agreed exit to an in-house checker if the spike succeeds.

To engineering: Kitab is a documentation rendering and testing companion aligned with Documentation-Driven Quality. Treat it as an isolated tooling dependency: pin it, vendor or fork it, run it only in CI or a docs build job, and keep it out of application runtime. 0.12 adds anonymous-class support in the intermediate representation and moves nikic/php-parser from 3.* to 4.* — budget time to re-validate parsing of existing snippets and confirm the parser's PHP floor against our CI image, since a major parser bump landed in a minor release. First validate PHP 8.x compatibility and CI footprint. In parallel, estimate the in-house alternative — a PHPUnit-driven harness that extracts and executes documented snippets — because that is likely the more durable path for a Laravel codebase. Success criteria: documented examples execute reliably, failures are actionable, and maintenance cost is lower than the support cost of stale docs.