Getting Started

Read this first: this is a Symfony 2 bundle, and you are on Laravel. There is no composer require path that lands you in a working state. idci/barcode-bundle registers itself through AppKernel, YAML/XML service definitions, and a Twig function extension. Laravel has no equivalent primitives. Your "getting started" is therefore a 30-minute triage, not an install.

Minimal triage steps (do these before writing any code):

License gate. GPL-3.0. If the product is distributed at all (desktop, on-prem, shipped container), stop here and escalate — this is a legal decision, not an engineering one. SaaS-only internal use is the only scenario where you proceed.
Dependency probe. In a throwaway branch:
```
composer require idci/barcode-bundle --dry-run
```
Expect it to fail against Laravel 10/11 and PHP 8.x because of symfony/symfony ~2.x, old psr/* pins, and possibly twig/twig version clashes. If it fails, the integration path is "fork," not "require," and the rest of this guide applies.
Read the source, in this order. This is your entire onboarding:
- composer.json — actual PHP/Symfony constraints, which decide feasibility.
- Twig/ (or Extension/) — the public surface. This is where the barcode actually gets rendered; in bundles of this vintage the generation logic is often inlined here rather than in a clean service.
- DependencyInjection/ and Resources/config/ — what services exist and whether the generator is injectable.
- Whatever produces the pixels (GD, TCPDF, ImageMagick, or an external binary). This determines your deployment footprint.

Where to look first if you need a working barcode this sprint: skip the bundle entirely. picqer/php-barcode-generator (MIT, framework-agnostic, actively maintained) gives you the same one-dimensional symbologies inside a Laravel service provider in under an hour. milon/barcode is the Laravel-native wrapper if you want zero provider code.

First use case to validate against: a fulfillment label — Code 128 rendering into a PDF (dompdf/snappy) as an inline SVG or a base64 PNG data URI. If your use case is QR/DataMatrix/PDF417, this package is the wrong engine regardless of framework; go to endroid/qr-code.

Implementation Patterns

Because there is no native Laravel path, there are exactly three patterns worth knowing. Pick deliberately.

Pattern A — Native Symfony 2 usage (context only)

If you ever read the source or port it, this is the shape it expects. It is not available to you on Laravel, but it tells you what the public API is:

// Symfony 2 AppKernel: register bundle, configure defaults
new IDCI\Bundle\BarcodeBundle\IDCIBarcodeBundle(),

{# Twig extension is the primary entry point #}
<img src="{{ barcode('code128', 'INV-2024-0042') }}" />

The reusable-service API advertised in the description lives behind the container; you inject it into a controller or service and ask it to render. Everything below assumes you've extracted that renderer into a standalone class in your fork.

Pattern B — Fork-and-extract into a Laravel service (the realistic path if forced)

This is the only viable way to use this package from Laravel. Budget a day, gate it on the license decision.

// 1. Vendor under an internal namespace, strip bundle metadata:
//    remove DependencyInjection/, Resources/config/, IDCIBarcodeBundle.php
//    keep only the generator. Expose it as one injectable class.

namespace App\Support\Barcode;

class BarcodeRenderer
{
    public function render(string $symbology, string $payload, array $opts = []): string
    {
        // adapted from the original Twig extension's body
    }
}

// 2. Bind it as a singleton; keep controllers thin.
// app/Providers/BarcodeServiceProvider.php
public function register(): void
{
    $this->app->singleton(BarcodeRenderer::class);
}

// 3. Expose it via a Blade component, not a directive — easier to test.
// resources/views/components/barcode.blade.php
<img src="{{ app(App\Support\Barcode\BarcodeRenderer::class)
    ->render($symbology, $payload, $options) }}" alt="{{ $payload }}" />

Capture a golden baseline before any edit. Render a handful of (symbology, payload, size) tuples from the original code, store the bytes, and assert against them after the extraction. With zero upstream tests, these snapshots are the only regression net you will ever have.

Pattern C — Deterministic caching (do this regardless of A or B)

Barcode rendering is pure output of a tuple. Cache it and this becomes a boring, cheap dependency.

public function render(string $symbology, string $payload, array $opts = []): string
{
    $key = 'barcode:' . hash('xxh128', serialize([$symbology, $payload, $opts]));

    return Cache::remember($key, now()->addYear(), function () use ($symbology, $payload, $opts) {
        return $this->renderer->render($symbology, $payload, $opts);
    });
}

Integration tips:

Emit SVG where the target allows it — smaller payload, no GD memory spike, scales crisply in PDFs. Fall back to PNG only for formats that don't accept SVG.
Return a data URI from the renderer so templates never need a route or a storage round-trip: data:image/svg+xml;base64,....
Put barcode rendering behind a job if the underlying engine shells out to ImageMagick or a CLI binary. Synchronous shell-outs under load are a concurrency footgun.
If you're wiring this into PDFs, render the barcode once and reuse the bytes across the whole document rather than re-generating per line.

Gotchas and Tips

Pitfalls

This will not composer require into Laravel, period. Do not spend a day fighting composer why-not. If the constraint probe fails, the answer is fork or drop — not vendor-patch Symfony 2 into Illuminate.
GPL-3.0 is the load-bearing risk. For a shipped product (container image, on-prem, desktop), the source-disclosure obligation applies to derivative works. Engineering cannot solve this; get a legal answer before writing a line.
Blade ≠ Twig. Any documentation or example invoking the Twig extension is inert on Laravel. Plan the translation to a Blade component or a direct service call from the start.
Repo name typo. The GitHub repo is BarecodeBundle (missing "c") in the README, while the package is barcode-bundle. Expect broken links and confusion when searching; that mismatch has also cost this repo discoverability.
Output engine is unknown until you read the source. It may be GD (per-request memory spikes proportional to resolution, no concurrency protection), TCPDF (heavy dependency), or a shelled-out binary (queue it). Each changes your ops story.
Check digits and quiet zones are on you. EAN/UPC/GS1-128 are spec-heavy. This package has essentially no test suite and no maintainer. If barcode correctness is business-critical (retail scanning, access control), a one-star abandoned bundle is not where that risk belongs.

Debugging

If a rendered barcode won't scan, it is almost always one of: wrong check digit, quiet zone too small, module width below the scanner's minimum, or a lossy PNG re-encode. Start by rendering to SVG at full resolution to rule out the pipeline.
If the generator throws at runtime, check whether it's actually delegating to an external binary on PATH — a common failure mode in bundles of this vintage on modern container images.

Config quirks

Defaults (default symbology, default size, output format) usually live in the bundle's DI extension under Resources/config/. In your fork, surface them as a config/barcode.php file rather than leaving them hardcoded inside the extracted renderer.
The Symfony 2 service definitions are XML/YAML; they will not be read by anything on Laravel. Delete them during extraction and don't try to preserve them for "compatibility" — there is no compatibility to preserve.

Extension points

There are effectively none you should rely on. The extension surface is the Symfony container and the Twig extension; both vanish in the port. Treat the extracted renderer as a closed class with one method, and wrap any new formatting choices (size, padding, format) in your code, not in a "plugin" against a dead bundle.

The honest recommendation

The right day-to-day pattern for a Laravel developer is to not adopt this package. Wrap picqer/php-barcode-generator (1D, MIT) or endroid/qr-code (2D, MIT) behind the same one-method service you'd have built around the fork. That gives you:

a permissive license with no legal conversation to have,
a maintained upstream taking security and PHP-version fixes,
roughly a day of integration — the same effort as the fork,
and no permanent fork maintenance tax on every future PHP/Laravel upgrade.

Reserve this bundle as a reference implementation to read once, then close the evaluation.

Barcode Bundle Laravel Package