E Commerce Extensions Extensionsbundle Laravel Package

Getting Started

This is almost certainly not a Laravel package. The ...Bundle suffix, the nitra Bitbucket namespace, and the nep (Nitra E-commerce Platform) prefix all point to a Symfony bundle. Before you write a single line of Laravel code, confirm that by reading composer.json in the repo root:

git clone https://bitbucket.org/nitra/nep-extensions-extensions.git
cd nep-extensions-extensions
cat composer.json       # look at "type", "require", "autoload", "extra"
find . -maxdepth 2 -type d | sort

What you are looking for, in order:

1. "type": "symfony-bundle" and a require on symfony/framework-bundle / symfony/dependency-injection → it is a Symfony bundle. Stop trying to composer require it into a Laravel app and see Implementation Patterns below.
2. src/Nitra...Extension.php or DependencyInjection/*Extension.php — the load() method in that class is the actual documentation for this package. It tells you every service, parameter, route file, and Twig path the bundle registers.
3. Resources/config/services.{xml,yaml,php} — the service IDs you would ever need to reference.
4. composer.json "require" — the real platform constraint. A bundle with no tags and no dependents usually pins to an old Symfony (^3.4/^4.0), which decides whether this is even installable on a current stack.

Because it is a private Bitbucket repo, installation needs a VCS repository entry plus credentials:

{
  "repositories": [
    { "type": "vcs", "url": "https://bitbucket.org/nitra/nep-extensions-extensions.git" }
  ],
  "require": {
    "nitra/e-commerce-extensions-extensionsbundle": "dev-master"
  }
}

and in CI, COMPOSER_AUTH with http-basic (Bitbucket username + app password, not your account password).

Your first real use case is diagnostic: get the bundle booting in a minimal Symfony app, run bin/console debug:container --show-private | grep -i nep, and inventory what it actually gives you. That inventory — not the README, which does not exist — is what you design against.

Implementation Patterns

Pattern 1 — Do not consume it from Laravel. With 0 stars and 0 dependents there is no interoperability layer, no Laravel service provider, no facade. If the extension logic is genuinely valuable, run it as a separate Symfony service (or a queue consumer) and talk to your Laravel app over HTTP/AMQP. This keeps the vendor bundle's Symfony coupling out of your app entirely, which matters because you will be maintaining this fork yourself.

Pattern 2 — Extract, don't embed. If you need the domain logic, copy the relevant classes into your own app/ or a first-party package and re-point their dependencies at Laravel contracts (Illuminate\Contracts\Cache, …\Events\Dispatcher). Bundles of this vintage typically touch ContainerAwareInterface, RequestStack, and Doctrine — the surface is small enough to port, and you then own it.

Pattern 3 — Symfony host, Laravel as the frontend. Bundle registered in a Symfony kernel, Laravel calling it as a downstream API. Register the bundle in config/bundles.php:

return [
    // ...
    Nitra\Ecommerce\Extensions\ExtensionsBundle::class => ['all' => true],
];

Then configure under config/packages/ and let Composer's symfony/flex (if present) handle the recipe — assume no recipe exists here and create the config file by hand from the Extension::load() signature.

Pattern 4 — Adapter in Laravel, if you truly must inline it. Wrap every bundle service behind an interface you define:

interface ExtensionsGateway
{
    public function getExtensions(): array;
}

final class ContainerExtensionsGateway implements ExtensionsGateway
{
    public function __construct(private ContainerInterface $container) {}

    public function getExtensions(): array
    {
        return $this->container->get('nep.extensions.manager')->getAll();
    }
}

Bind it in a service provider, and never let a bundle class name leak past that boundary. When you eventually fork or drop the package, one file changes.

Pattern 5 — Vendor the fork. Given no tags and no maintainer responsiveness signals, treat dev-master as a liability. Fork to your own namespace, tag it 1.0.0, require that. Composer's path repository works well for the interim:

{ "type": "path", "url": "packages/nep-extensions", "options": { "symlink": true } }

Gotchas and Tips

• Name mismatch. The Composer name (nitra/e-commerce-extensions-extensionsbundle) and the repo name (nep-extensions-extensions) do not agree, and the nitra/e-commerce-* vendor prefix suggests an older monorepo split. Verify the "name" field in composer.json matches what you require, or Composer will report a confusing "could not be found" rather than a version error.
• No tags = no stability. Even if tagged internally, minimum-stability defaults to stable. You will need dev-master#<commit-sha> pinned by hash. Pin the SHA in composer.lock and treat upgrades as code review, not composer update.
• Abandoned Symfony majors. ContainerAwareInterface was removed in Symfony 5; services.yaml autowiring defaults and Controller as a service changed around 4.4/5.0. If Extension::load() uses XML service definitions with <argument type="service">, it probably still loads — if it uses getDefinition() with string class names, it may not. Run debug:container before and after to diff.
• Private repo auth in CI. composer install in a pipeline fails with 403 unless COMPOSER_AUTH is set. Bitbucket app passwords are required (account passwords no longer work for Git over HTTPS). Also set "secure-http": false only if you are pointing at an internal mirror — never for bitbucket.org.
• Debugging is container-first. bin/console debug:container <service-id>, debug:router, debug:event-dispatcher, lint:container. Because there is no documentation, these four commands are your documentation. lint:yaml/lint:xliff catch bad resource paths in the bundle's Resources/ tree, which is a common failure mode for old bundles that moved their directory layout.
• Extension points worth knowing. Compiler passes (scan the bundle for *CompilerPass classes — those are the intended customization hooks), service decoration (decorates: nep.extensions.manager), and event subscribers. Prefer decoration over editing vendor code; you keep the fork mergeable.
• No dependents means no known-good usage examples. Anything you learn about its intended semantics comes from method names and tests. Check for a Tests/ directory — if there is one, it is the only executable spec you have; run it against your target PHP/Symfony versions before trusting anything.
• Assessment of risk. Score 0, no stars, no dependents, no README: budget for this being effectively unmaintained. Suitability is limited to (a) reading it for domain ideas, or (b) a short-lived bridge inside a Symfony app you already control. Do not make a Laravel application's runtime depend on it.