Php App Core Laravel Package

Getting Started

Treat this as a greenfield dependency: 0 stars and 0 dependents means you are the first integrator, and there is no blog post, Stack Overflow answer, or GitHub issue thread waiting to help you. Budget a half-day spike before it touches a real app.

1. Install into a throwaway Laravel app first, pinned to an exact version:

   composer require xver/php-app-core:1.2.3   # exact, no caret
   composer show xver/php-app-core
   

2. Read vendor/xver/php-app-core/composer.json before anything else. This single file answers most of your questions:
   • require — does it constrain illuminate/* or php? A hard illuminate/support:^9 will silently hold your Laravel 11 app back.
   • extra.laravel.providers / extra.laravel.aliases — if absent, there is no package auto-discovery and every wiring step is manual.
   • autoload.psr-4 — confirm the namespace and check it does not collide with your App\ tree.
3. Open vendor/xver/php-app-core/src/ and tests/ next. With no docs and no community, the test suite is the specification. If tests/ is empty or missing, treat every public method as undocumented and subject to change.
4. Check the GitHub README for an explicit "Laravel" section. Do not infer Laravel support from a Laravel-adjacent package name. php-app-core reads like a framework kernel/bootstrap package, which is often a peer to Laravel rather than a plugin for it.
5. First use case: pick one leaf concern the package actually owns — config resolution, a container wrapper, an app bootstrap sequence — and exercise it in a single isolated Artisan command or queued job. Do not modify bootstrap/app.php or public/index.php until the spike is green.

Implementation Patterns

Adapter boundary (do this by default). Define your own contract in app/Contracts/, implement it in a thin class that delegates to the package, and bind it in a service provider. When the package breaks or you swap it out, you change one binding instead of grepping 40 call sites.

If it ships a ServiceProvider:

• Register in bootstrap/providers.php (Laravel 11+) or config/app.php (10 and below).
• Publish config immediately and commit it: php artisan vendor:publish --provider="Xver\PhpAppCore\...ServiceProvider". A committed config file turns every upstream default change into a reviewable diff.
• Mirror package options into your own config/php-app-core.php and read them only via config(), never through the package's own config singleton — otherwise config()->set() in a test won't reach it.

If it ships its own kernel or bootstrap sequence: treat it as a sidecar, not a plugin. Give it a standalone entry point (bin/worker.php) or its own container/process. Two bootstrappers running in one request is the classic failure mode: competing error handlers, competing set_exception_handler calls, and global state that leaks between them.

Testing: bind a fake implementation in tests/TestCase::setUp(). Never assert on package-internal objects — assert on your contract. This is what keeps the dependency swappable when the package goes quiet.

Upgrades: pin exact versions in composer.json, upgrade deliberately, and run the package's own test suite plus yours on your target PHP version before bumping. With zero dependents there is no canary population; you are the canary.

CI hardening: add composer audit, a PHP version matrix (8.1–8.4), and composer why-not xver/php-app-core <version> in your dependency-review job.

Gotchas and Tips

• AGPL-3.0 is the decision, not a detail. The network clause means offering the software as a service can obligate you to release source for the combined work. For a typical Laravel SaaS this is a legal review, a hard no, or a re-architecture into a separately deployed process (and even then it is not clearly safe). Resolve this before the spike, not after.
• Zero dependents means zero security telemetry. No dependents, no advisories surfaced in the ecosystem, no one else to notice a malicious release. Watch the repo and tags yourself, and consider vendoring a reviewed commit rather than tracking Packagist.
• The release date is worth a sanity check. 2026-10-14 is either a metadata artifact or a mis-tagged build; diff the Packagist version against the actual git tag (git log inside vendor/xver/php-app-core) before trusting the version number you pinned.
• Low score (≈19.7/100) tracks with what you'll find: thin docs, no semver discipline guarantee, API churn between minor versions. Assume breaking changes in patches.
• No illuminate/* constraints is common in low-adoption packages — it will install happily and then fail at runtime against a Laravel version it never tested. Verify by actually booting the app, not by composer require succeeding.
• Autoload/global-state conflicts: if the package calls ini_set, registers a global error handler, or defines constants at file scope, it will interact badly with Laravel's own bootstrap. Grep the source for ini_set, set_error_handler, define(, and $GLOBALS before integrating.
• Debugging without docs: composer show --all xver/php-app-core for the full version/dependency graph, then read the constructor of the main entry class — the constructor arguments are effectively the package's public contract.
• Extension points to look for: interface declarations in src/Contracts/, a config/ directory, and any event/dispatcher usage. If none of those exist, the package is meant to be used as-is and you should keep it at arm's length behind your adapter.