Base Bundle Laravel Package

Getting Started

wizin/base-bundle is a Symfony bundle, not a Laravel package — first and most important caveat. There is no ServiceProvider, no package auto-discovery, and no config/*.php publish step. If your application is Laravel, the only realistic use is borrowing ideas/source, not composer require-ing it into your app.

For a Symfony host application:

1. composer require wizin/base-bundle — verify the package actually resolves on Packagist and that the wizin/base-bundle name matches the repo (WizinBaseBundle). With 0 dependents there is a real chance the published name differs from the repo name, or that it has never been tagged.

2. Register manually in config/bundles.php:

   return [
       // ...
       Wizin\BaseBundle\WizinBaseBundle::class => ['all' => true],
   ];
   

3. Look first at these files in the repo before writing code:

   • src/WizinBaseBundle.php — confirms the namespace and bundle name you must use in bundles.php.
   • DependencyInjection/ — the Extension class reveals the config root (wizin_base by convention) and mergeable parameters.
   • Resources/config/services.* (or config/services.php) — what services are registered, and whether they're private/autowired.
   • composer.json autoload block — PSR-4 prefix must match the namespace above or nothing will resolve.

4. First use case: extend whatever base classes the bundle exposes. Base bundles of this shape (0 stars, MIT, no docs) almost always ship a small set of BaseEntity / BaseController / BaseRepository-style classes meant to be subclassed. Try one subclass in isolation and run bin/console debug:container and bin/console cache:clear before committing to the pattern across the app.

Bottom line for getting started: treat this as an untrusted, undocumented dependency. Budget an hour to read the whole src/ tree (it is small) before you write anything against it.

Implementation Patterns

Because this package is effectively a "base classes" bundle rather than an integration bundle, the viable patterns are:

Subclassing the base layer. The intended workflow is inheritance: your domain entities/controllers extend the bundle's base types, and you inherit whatever shared behavior (timestamps, soft-delete flags, generic CRUD, response helpers) it provides.

// entity
use Wizin\BaseBundle\Entity\BaseEntity;

class Invoice extends BaseEntity
{
    // bundle-provided fields come from the parent via @MappedSuperclass
}

Before adopting, confirm the parent is a @MappedSuperclass / #[MappedSuperclass] rather than a concrete entity — otherwise Doctrine will try to map a table you don't control.

Service decoration instead of fork. If a bundle service is useful but almost-right, decorate it in your app config rather than editing vendor code:

services:
  App\Service\MyThing:
    decorates: wizin_base.some_service
    arguments: ['@.inner']

This survives composer update and lets you keep the bundle at a pinned version.

Compiler passes for extension. If the bundle's extension points are thin, look for tagged services or an interface it resolves from the container, and add your own compiler pass in Kernel::build() to inject additional implementations:

protected function build(ContainerBuilder $container): void
{
    $container->addCompilerPass(new MyWizinPass());
}

Config override via the bundle's config tree. Whatever Configuration.php defines can be overridden in config/packages/wizin_base.yaml. Start by dumping it:

bin/console config:dump-reference wizin_base

For Laravel teams specifically: if you want the functionality, don't bridge the bundle. Copy the parts of src/ you need into app/Support/ and convert the container wiring to a ServiceProvider. Bridging a Symfony bundle into Laravel is almost never worth it and there's no maintained bridge for packages this small.

Gotchas and Tips

• Zero stars, zero dependents, no docs. There is no community to answer questions, no Stack Overflow history, and no issue tracker activity to gauge. Assume no one else is running this in production and that you are the de facto maintainer the moment you install it. Pin the version in composer.json and consider vendoring.

• No tags = no stable versions. Check git tag. With projects this size, you'll often get dev-main only, which means composer update can silently change behavior. Use "wizin/base-bundle": "dev-main#<commit-sha>" if tags are absent.

• Namespace/bundle-name mismatch. The repo is WizinBaseBundle but the package is wizin/base-bundle. Confirm the class in src/ and the getContainerExtension() return value before registering in bundles.php — a wrong name there gives a confusing "bundle not found" during cache warmup.

• Autoload is the #1 failure mode. If the PSR-4 prefix in composer.json doesn't match the actual namespace, you get Class not found at cache warmup with no further hint. Run composer dump-autoload -o and composer validate first when something breaks.

• Base classes are a lock-in trap. Subclassing a bundle's BaseEntity couples your domain model to a package with one maintainer and no releases. If you're doing this, isolate the inheritance to a thin App\Entity\AbstractEntity that extends it — one file to change if the bundle dies.

• Doctrine mapping conflicts. If the base entity declares fields (id, createdAt, deletedAt) and your app also uses a trait or another base class for the same fields, you'll get duplicate column errors only at doctrine:schema:validate time, not at boot. Run schema validation immediately after install.

• Private services by default. Modern Symfony makes bundle services private. If you need $container->get('wizin_base.foo') and it's private, don't fight it — inject it. If the bundle really offers no public API, that's a signal the extension points are compiler passes or subclassing.

• Debugging workflow when the bundle misbehaves:

  bin/console debug:container --show-private | grep -i wizin
  bin/console debug:config wizin_base
  bin/console lint:container
  bin/console cache:clear -vvv
  

• No tests to lean on. With a repo this small, assume test coverage is nil. Write your own smoke test that boots the kernel with the bundle registered — that catches autoload, DI, and config-tree breakage in one shot.

• Extension points to check before forking: Symfony Events dispatched by the bundle, tagged services, interfaces for strategy injection, and the Configuration tree. If none of these exist, forking (or copying the classes) is genuinely the lower-risk path than composer require.

• License is MIT, so copying classes into your own app/ is legal — often the sanest option for a 0-dependency package on a Symfony-only feature set you're trying to use from Laravel.