Core Bundle Laravel Package

Getting Started

This is a low-traffic, single-maintainer bundle with no published documentation and no dependents, so treat the repository itself as the source of truth before writing any code.

1. Install and inspect first, not last.

   composer require spipu/core-bundle
   

   Then immediately open vendor/spipu/core-bundle/ and read composer.json for the exact PHP and Symfony version constraints. Do not assume it supports your Symfony major — check the require block before registering it.

2. Register the bundle in config/bundles.php:

   Spipu\CoreBundle\SpipuCoreBundle::class => ['all' => true],
   

   If the class name differs, find it in the bundle root (*Bundle.php).

3. Look here first, in this order:

   • src/DependencyInjection/ — the extension and Configuration.php tell you every config key that actually exists. This is more reliable than any README.
   • src/Resources/config/ — service definitions; this is what gets autowired into your container.
   • src/ subfolders — base classes, traits, and helpers are usually the real deliverable of a "core" bundle.

4. First use case: a "core" bundle of this kind is almost always consumed by inheritance or traits (shared base entity, base repository, common DTO/exception types) rather than by calling services directly. Start by checking whether your intended class can extend or use something from src/, then wire one service and confirm it resolves:

   bin/console debug:container --show-private | grep -i spipu
   

5. Smoke test the container before building features: boot the app in dev, clear cache, and confirm no ServiceNotFoundException or config-tree errors. Given the absence of community usage, a broken container is the most likely first failure.

Implementation Patterns

Extend the provided base classes rather than copying them. Core bundles typically ship abstract entities, repositories, or managers. Subclass them so upstream bug fixes land in your code:

use Spipu\CoreBundle\Entity\AbstractEntity; // verify exact FQCN in src/

class Order extends AbstractEntity
{
}

Verify which methods are final or private before committing to inheritance — an abstract base with a private constructor or final methods will force a different approach.

Consume traits for cross-cutting behavior. If the bundle ships traits (timestamps, UUIDs, slugging), prefer use over duplicating fields, but check for property/method collisions with your own base classes.

Import the bundle's service config explicitly if autowiring is off. If you are not using services.yaml autoconfigure, you may need:

# config/services.yaml
imports:
    - { resource: '@SpipuCoreBundle/Resources/config/services.yaml' }

Verify the actual filename — it may be .xml or .php.

Decorate, don't fork. If a service in the bundle is close but not exact, use Symfony service decoration to wrap it:

App\Service\MyWrapper:
    decorates: spipu.core.some_service
    arguments: ['@.inner']

This keeps you upgrade-safe when the package releases a new version.

Isolate the dependency behind an interface. Because the package is obscure and could be abandoned, wrap its services in your own thin adapter. If it disappears from Packagist, you replace one adapter, not fifty call sites. This is the single most valuable pattern for a package with 0 dependents.

Pin the version. In composer.json, require an exact or tight constraint ("spipu/core-bundle": "1.2.*") rather than ^1.0. With one release cadence and no downstream users, minor bumps are untested against real consumers.

Vendor a fork if you need fixes. With no dependents, PRs may sit. Fork to your org, patch, and point Composer at the VCS repo:

"repositories": [{ "type": "vcs", "url": "[email protected]:yourorg/core-bundle.git" }]

Gotchas and Tips

• Zero stars and zero dependents means zero battle-testing. There is no Stack Overflow corpus, no issue history to learn from, and no guarantee the current release was ever installed by anyone but the author. Budget time for reading source.
• The "last release" date may be in the future or otherwise unreliable depending on how Packagist metadata is read; confirm the actual tag with composer show spipu/core-bundle --all and check what composer.lock resolved to.
• Config quirks: if the extension's Configuration.php defines a root node, your YAML key must match it exactly (often spipu_core:, not spipu_core_bundle:). A mismatched root silently does nothing — Symfony only errors when the node is requiresAtLeastOneElement or similar. Validate with:

  bin/console config:dump-reference spipu_core
  

• Autowiring surprises: core bundles often define services with explicit IDs and no autowiring aliases. If debug:autowiring does not list your service, inject by ID or add an alias in your own config.
• Debugging: bin/console debug:container Spipu --show-private and bin/console lint:container are your fastest tools when a service fails to load. bin/console cache:clear after any config change; stale container caches cause phantom errors.
• Extension points: look for interfaces the bundle exposes (e.g. *Interface in src/) and for compiler passes in src/DependencyInjection/Compiler/. Compiler passes are the intended hook for tagging your own services into the bundle's pipeline.
• Missing README is a signal, not an obstacle. If README.md is one line ("Spipu Core Bundle"), do not expect semantic versioning guarantees. Treat every update as a potential BC break and run your test suite on upgrade.
• PHP/Symfony version drift is the top risk. A bundle with no dependents is unlikely to have CI covering current Symfony majors. Check .github/workflows/ for the matrix; if it only tests Symfony 5.x, do not run it on 7.x without a smoke test.
• License is MIT, so forking and maintaining privately is legally clean — plan for that contingency given the maintenance risk.

Bottom line: usable, but only after reading the source and isolating it behind your own adapter. Do not make it load-bearing architecture.