Dico Laravel Package

Getting Started

alis/dico is a small, low-adoption package (3 stars, 0 dependents) described as a "Dictionary data manager." Treat it as a reference-data / key-value store for Laravel rather than a mature framework component, and verify assumptions against the source before building on it.

Install and discover

composer require alis/dico
php artisan vendor:publish --tag=dico   # name may differ; run `php artisan vendor:publish` and pick the provider
php artisan migrate                    # only if the package ships migrations

Look here first, in this order

1. composer.json — Laravel and PHP constraints, autoload namespace (do not assume ALIS\Dico).
2. src/ — service provider, facade, models/repositories. This tells you whether storage is config, file, or database.
3. config/dico.php (after publishing) — storage driver, table names, locale settings, cache TTL.
4. database/migrations — whether it owns tables or expects you to provide them.
5. tests/ and the README — the only reliable signal of intended API; with 0 dependents there is no community usage to fall back on.

First use case

Replace hardcoded lookup arrays (statuses, categories, country lists, units, feature flags) with a dictionary you can edit at runtime without a deploy:

// before
$statuses = ['draft', 'review', 'published'];

// after (method names illustrative — confirm against src/)
$statuses = Dico::get('content.statuses');

Seed the dictionary during setup, read it through the facade, and keep a typed wrapper of your own around it so the package is replaceable later.

Implementation Patterns

Wrap the package behind your own repository

With near-zero adoption, the cheapest insurance is an interface boundary. Bind a DictionaryRepository contract in a service provider and implement it with alis/dico. Swapping to a plain Eloquent table or config() later becomes a one-file change.

interface DictionaryRepository {
    public function get(string $key, mixed $default = null): mixed;
    public function put(string $key, mixed $value): void;
}

$this->app->bind(DictionaryRepository::class, DicoDictionaryRepository::class);

Reference-data seeding

Populate dictionaries in a dedicated seeder so environments are reproducible. Make seeding idempotent (updateOrCreate on the dictionary key) so re-running does not duplicate rows, and run it in deploy pipelines rather than ad-hoc tinker sessions.

Enum-style usage

Back form selects, validation (Rule::in(...)), and display labels with the same dictionary call so the three never drift. Cast the retrieved value to a typed collection/DTO at the boundary rather than passing raw arrays through your domain.

Caching reads

Dictionary lookups are read-heavy and write-rare. Cache the resolved value per key, and invalidate on write. If the package does not invalidate automatically (likely), attach a model observer or wrap put() in your repository to forget the cache key.

Multi-locale data

If the package supports locale-scoped dictionaries, store per-locale entries with a composite key (group.key.locale) and fall back to a default locale explicitly in your repository. Do not rely on an implicit fallback you have not tested.

Testing

Use RefreshDatabase, seed a minimal fixture dictionary in setUp, and assert through your repository interface rather than the facade. If the package provides a facade, Facade::fake() or a container swap keeps tests independent of the storage driver.

Gotchas and Tips

Treat the dependency as unvetted. Three stars and zero dependents means no production battle-testing you can observe. Pin an exact version, read the source before merging, and check the commit history for staleness. Have a removal plan from day one.

Verify the namespace and service provider. Do not copy-paste ALIS\Dico\... from assumptions. After install, run php artisan package:discover -v and inspect vendor/alis/dico/composer.json for the real PSR-4 mapping.

Cache invalidation is the classic failure. Writes that bypass the package (direct DB updates, seeders run outside the app) will leave stale cache entries. Standardize all writes through your repository, and add a cache-busting command hook to deploys.

Publish and review migrations before running them. With a tiny package, migration column types, indexes, and table names may not match your conventions. Publish, diff against your schema, and edit before migrate.

Watch Laravel/PHP version constraints. Small packages often lag major framework releases. Confirm the constraint in composer.json covers your Laravel version; if it does not, do not force-install with --ignore-platform-reqs in production.

Config quirks. Check whether the storage driver defaults to file, config, or database, and whether the default is safe for multi-server deployments. A file-backed dictionary on ephemeral containers will silently reset on redeploy.

Validation and authorization on editable dictionaries. If you expose an admin UI or accept writes, guard against mass assignment and authorize edits — dictionary data often feeds validation rules, so unauthorized writes become a soft input-validation bypass.

Debugging tips. php artisan tinker to call the facade directly; log the resolved key and cache key in your repository; php artisan config:clear after editing published config, since cached config will mask changes.

Extension points. The realistic levers are: published config, container bindings (swap the repository implementation), model extension/observers, and wrapping the facade. Avoid forking unless you intend to maintain the fork.