Stubs Laravel Package

Product Decisions This Supports

• Developer-experience investment for a niche stack. This package only exists to make the Tarantool PHP connector (the PECL extension) legible to IDEs and static analysers. Adopting it is a small, explicit statement that the team cares about IDE autocompletion and onboarding friction for engineers working against a C extension that has no readable PHP source.
• Build vs. buy for internal tooling. The realistic alternative is generating stubs in-house from the extension's reflection data or hand-writing phpdoc blocks. This package is the "buy" (or rather, "borrow") option in that trade-off: near-zero cost versus a small ongoing maintenance and staleness liability.
• Stack commitment signal. Wanting this package implies you have committed to the native extension path rather than a pure-PHP client. If you are still deciding between the extension (performance, native protocol) and a userland connector, this package's existence is a minor point in the extension's favour — but a minor one, and it should not drive the decision.
• CI and static-analysis roadmap. Stubs feed PHPStan/Psalm and IDE inspection. Whether to include them in require-dev and your analysis baseline is a concrete decision this package informs, with direct impact on the type-safety posture of connector-touching code.
• Use cases it enables in day-to-day work: autocompletion and signature hints in PhpStorm/VSCode, fewer typo-class bugs against extension classes and functions, faster ramp-up for engineers unfamiliar with Tarantool's API surface, and less time reading C headers or upstream docs.
• Risk/health triage. Zero stars, zero dependents, and a zero score is itself a data point. Treat this as a low-signal, low-adoption artefact: usable as a convenience, not something to build a standard on without verification.

When to Consider This Package

Consider it when all of the following hold:

• You are using the native Tarantool PHP extension (not a pure-PHP connector, which typically ships its own phpdoc and needs no stubs).
• Your team works primarily in IDEs and/or runs PHPStan or Psalm against code that touches the connector.
• You are willing to pin a version, review the stub contents once, and accept that it is a dev-only dependency with no runtime footprint.
• The stub surface still matches the extension version you deploy — verify this before adoption, because a stale stub set is worse than none: it produces confidently wrong autocompletion and false static-analysis results.

Look elsewhere, or skip it, when:

• You use a userland Tarantool client, in which case the package is simply irrelevant.
• The stubs lag your extension version and no maintainer response is evident. Given the adoption numbers, assume low maintenance velocity until proven otherwise; be prepared to fork or vendor it.
• Your need is deeper than autocompletion — e.g. accurate generic types, return-type narrowing on response decoding, or strict static analysis. Stubs of this kind typically get you signatures, not rich types, and a hand-curated internal stub file may serve you better.
• Your organisation requires a maintained, supported dependency with a security and release cadence. This does not meet that bar; generating stubs internally from reflection is a few days of work and removes the external dependency entirely.

Adoption mechanics worth deciding up front: add under require-dev, vendor a pinned copy if you need reproducibility, and exclude stub files from your own coverage and style gates.

How to Pitch It (Stakeholders)

To executives: This is a free, low-risk developer-convenience package for teams building on Tarantool's PHP extension. It gives engineers IDE autocompletion for the extension's API, which modestly reduces typo-class defects and shortens onboarding for anyone new to Tarantool. It ships nothing to production — it is a development-only dependency — so it carries no runtime, security-surface, or performance risk. The main caveat is maturity: the project shows no meaningful adoption and may not track the extension's releases, so we should treat it as a pinned convenience we can fork or replace with internally generated stubs. Recommendation: adopt provisionally behind a version pin, verify stub coverage against our extension version, and revisit only if it goes stale.

To engineering: Add it to require-dev so PhpStorm and PHPStan can resolve the connector's classes and function signatures instead of flagging everything as undefined. Pin the version, sanity-check the stubs against the extension version we actually run, and expect to either vendor it or generate our own stubs from reflection if it drifts. Do not let it into production dependencies, and do not treat its type hints as ground truth beyond signatures until someone has reviewed them.