Dime Timetracker Bundle Laravel Package

Getting Started

Before anything else, correct the framing: phpugl/dime-timetracker-bundle is a Symfony 2 bundle, not a Laravel package. It expects AppKernel registration, a services.yml file, FOSRestBundle annotation routing, and Doctrine ORM entities. There is no service provider, no facade, no config publishing, and no migrations/ directory. Running

composer require phpugl/dime-timetracker-bundle

inside a Laravel project will fail immediately on php and symfony/* constraints (Symfony 2.3–2.8, PHP 5.3–5.6). Do not spend more than five minutes on this path.

Where to look first if you are evaluating it:

1. composer.json — record the exact php, symfony/*, friendsofsymphony/rest-bundle, and jms/serializer constraints. This is your compatibility answer.
2. Entity/ — the actual value: the domain model (User, Project, Activity, Timeslip). Read this before any code.
3. Controller/ and Resources/config/routing/ — the REST surface. Count endpoints. If it's under ~15, rewriting is cheaper than integrating.
4. Resources/config/services.yml — how the domain services are wired, useful as a checklist when you build your own.

The realistic first use case is not "install it." It is a 2–4 day spike where you clone the repo and map its resource taxonomy onto Laravel migrations + Eloquent models. The thing you actually ship is your own TimeslipController, not this bundle.

Implementation Patterns

The only pattern that works in a Laravel codebase is HTTP integration over a running Dime instance behind a repository interface — the bundle itself is a controller/serializer layer you can rewrite in a sprint.

Repository + DTO pattern (recommended):

interface TimeslipRepository {
    public function forProject(int $projectId, CarbonImmutable $from, CarbonImmutable $to): Collection;
}

class HttpTimeslipRepository implements TimeslipRepository {
    public function forProject(...) {
        return Http::baseUrl(config('dime.base_url'))
            ->withBasicAuth(config('dime.user'), config('dime.pass'))
            ->get('/api/timeslips', ['project' => $projectId, ...])
            ->throw()
            ->collect('timeslips')
            ->map(fn ($row) => TimeslipDTO::fromDime($row));
    }
}

Bind it in AppServiceProvider. Controllers and reporting jobs depend on the interface, never on Dime's payload shape. This is the Laravel equivalent of the bundle's "wiring services into the container" — except you control it.

Domain modeling pattern. Mirror the bundle's entity graph if you are building your own schema:

• users — the tracker (may be external/Dime-owned)
• projects — belongs to a client, has many activities
• activities — the billable category
• timeslips — belongs to user + project + activity, has duration (minutes) and date

Use integer minutes for duration and a date (not datetime) for timeslip.date; this matches Dime's semantics and avoids most timezone drift.

Service provider translation. The bundle's services.yml is effectively a list of $this->app->bind() calls. If you're forking any logic, translate one-to-one: Dime\TimeslipService → App\Services\TimeslipService, registered in AppServiceProvider. Don't try to reuse the Symfony DI config verbatim — you'll be fighting autowiring.

Sidecar pattern (only if you must run the legacy code). Deploy it in its own Symfony 2 container behind a reverse proxy, expose only the endpoints you need, and treat it as an anti-corruption layer. Your Laravel app talks to your contract via the repository above; the sidecar is swappable.

Testing. Use Http::fake() with fixtures captured from your spike against a live Dime. Record request shapes and response payloads as JSON files under tests/Fixtures/dime/. These become your contract tests — you want them to fail loudly if upstream drifts.

Gotchas and Tips

• Framework mismatch is dispositive, not cosmetic. A Symfony bundle has no boot(), no register(), no artisan. There's no shim. Don't argue with the composer.json; argue with the framework choice.
• EOL runtime. PHP 5.x/7.x and Symfony 2 accumulate CVEs. Even a read-only bridge puts unpatched code on your risk register, and it will surface in every security scan.
• Zero community is a real operational cost. 12 stars, 0 dependents, no release cadence. There is no Stack Overflow corpus for the failure modes you'll hit. Every bug is a source-read.
• Timezone and duration handling is the real bug surface — not the framework. If you copy the schema, pin durations to integer minutes and dates to date columns, and write a reconciliation test that compares your aggregates against the source on a schedule. An off-by-one-hour error in a timeslip is a billing dispute, not a bug ticket.
• Silent schema drift. If someone upgrades the Dime instance independently, jms/serializer breaks at runtime with no contract to catch it. Consumer-driven contract tests are your only defense; add response validation in the adapter.
• Auth fragility. Legacy bundles typically assume HTTP Basic or an old OAuth bundle. Credential rotation, token expiry, and 401 handling need explicit code — you get none of it from the bundle, and Laravel's guard system doesn't apply.
• Write-path partial failure. A timeslip created locally but rejected upstream is a phantom billable. If you ever write back, use idempotency keys and a reconciliation job; retries alone will duplicate entries.
• Debugging is against Symfony conventions. Error pages route through the Symfony kernel and FOSRestBundle exception listeners. dd()/ray() won't help. You're reading source and var_dump-ing inside a container.
• Extension points you can actually use: there are none in Laravel. If you fork, the touch points are the entity classes (schema) and services.yml (wiring) — those are the two files to read carefully before any rewrite.
• License check first. If LICENSE is unclear or absent, stop evaluation immediately; a fork without clean licensing is a legal problem, not an engineering one.

Bottom line for a Laravel developer: git clone it, spend a week reading the entities and route conventions, then build the equivalent with Eloquent, Http, and a repository interface. Do not add it to composer.json — the framework mismatch alone makes that a non-starter, and the maintenance burden makes it a bad idea even if it weren't.