Core Bundle Laravel Package

Getting Started

netbull/core-bundle is a Symfony bundle that ships reusable "core" building blocks (base entities/models, traits, helpers, and shared service wiring) so you don't reimplement them in every project. Because it has effectively zero public adoption and no ecosystem docs, treat it as an internal library you need to read before trusting.

Minimal setup:

composer require netbull/core-bundle

Then register it in config/bundles.php (Symfony Flex will usually do this if the package ships a recipe; assume it does not and add it manually):

return [
    // ...
    Netbull\CoreBundle\NetbullCoreBundle::class => ['all' => true],
];

Where to look first, in this order:

1. src/ — the bundle root. List the namespaces to see what it actually offers (Entity/, Model/, Traits/, Util/, Form/, Twig/, Doctrine/, etc.). This tells you more in 30 seconds than any README will.
2. composer.json — check the require block for the supported Symfony and PHP versions. A low-star bundle is often pinned to an older Symfony major; if it requires symfony/framework-bundle: ^5.4 and you're on 7.x, stop here.
3. DependencyInjection/ and Resources/config/ — see which services get registered and under what IDs, and whether anything is auto-registered or must be opted into.
4. README.md — if it exists at all, it's usually a stub; use it only to confirm intent, not behavior.

First real use case: pick the single most valuable primitive it exposes — typically a base entity class or a Timestampable/Uuid-style trait — and adopt it in one throwaway entity before refactoring your domain. A "core" bundle's value is concentrated in a handful of classes; validate those in isolation rather than importing the whole thing.

Implementation Patterns

Inheritance-first, not service-first. Core bundles usually expose abstract base classes (AbstractEntity, BaseModel) rather than services. The idiomatic pattern is to extend them:

use Netbull\CoreBundle\Model\AbstractEntity;

class Product extends AbstractEntity
{
    // your fields; id/createdAt/updatedAt inherited
}

Inheritance chains are harder to undo than service composition, so only extend where the bundle's base genuinely matches your domain. Otherwise use the traits directly — they compose better with existing base classes.

Doctrine integration. If the bundle supplies traits, map them explicitly in your entity config rather than assuming auto-mapping:

#[ORM\Entity]
#[ORM\HasLifecycleCallbacks] // only if the bundle's traits need it
class Product
{
    use TimestampableTrait; // confirm the trait's field names before mapping overrides
}

Check whether the bundle registers Doctrine subscribers/listeners (EventSubscriber/, EventListener/) — these often drive timestamps or slug generation and can silently conflict with your own.

Service decoration over replacement. If the bundle registers helpers (formatters, sluggers, paginators), don't fight its service IDs. Decorate:

services:
    App\Core\DecoratingSlugger:
        decorates: netbull_core.slugger
        arguments: ['@.inner']

This keeps you on the bundle's upgrade path while adding your behavior.

Configuration. If the bundle has a Configuration.php, it likely exposes a small tree (table prefixes, pagination limits, feature toggles). Publish and pin it explicitly:

# config/packages/netbull_core.yaml
netbull_core:
    # copy keys from Configuration.php — do not guess

Set these values in config rather than passing options per call site; it centralizes the behavior when you eventually replace the bundle.

Workflow for adopting in a live app. (1) Install on a branch. (2) Add one entity / one service using the bundle. (3) Run bin/console debug:container | grep netbull and debug:router if it ships controllers. (4) Run your test suite and a migration diff. (5) Only then refactor other models. This staged approach contains the blast radius of a low-star dependency.

Gotchas and Tips

• It is a low-adoption dependency. Zero stars and zero dependents means no community debugging, no Stack Overflow answers, and no guaranteed maintenance. Pin it in composer.json ("netbull/core-bundle": "x.y.*"), and consider vendoring or forking if it becomes load-bearing. Budget for the possibility you maintain it yourself.
• Symfony version skew. Verify composer.json constraints against your Symfony/PHP versions before registering the bundle. A "released 2026-06-11" date doesn't guarantee it supports the newest Symfony; tags may be maintenance releases on an old branch. Run composer why-not netbull/core-bundle <your-symfony-version> if install fails.
• Missing Flex recipe. Assume no auto-registration. If config/bundles.php isn't updated and services aren't visible, you'll get confusing "service not found" errors — add the bundle class manually and clear cache.
• Silent service-ID collisions. Core bundles often register generic IDs (app.helper, core.manager) that can clash with your own. After install, diff bin/console debug:container --show-private against a pre-install snapshot to catch what got registered.
• Doctrine mapping surprises. Base entities frequently assume specific column names (created_at, updated_at, deleted_at) and types. Check the trait/base class source before writing migrations; bin/console doctrine:schema:validate and doctrine:migrations:diff will surface mismatches.
• Lifecycle callbacks only run when registered. If timestamps aren't populating, the usual cause is a missing #[ORM\HasLifecycleCallbacks] on your entity or a Doctrine event subscriber that's not enabled. Grep the bundle for prePersist/preUpdate.
• Debugging entry points. bin/console debug:container netbull (list tagged services), bin/console debug:config netbull_core (echo the resolved config tree), and bin/console lint:container are your fastest triage tools.
• Extension points. Before modifying vendor code, check whether the bundle exposes interfaces or abstract classes you can implement (*Interface, Abstract* in src/). If it doesn't, decorate or wrap its services rather than fork — forking a zero-adoption bundle is a commitment.
• Test coverage is your responsibility. With no dependents, there's no external signal that anything works. Write at least one integration test per adopted primitive (entity round-trip, service call, trait behavior) so a future composer update break is caught by you, not production.
• Have an exit plan. Keep your usage thin — a handful of traits and base classes — so that replacing the bundle later is a refactor, not a rewrite. If you find yourself importing ten-plus classes from it, that's the signal to vendor it or copy the relevant code into your own App\Core namespace.