Data Dictionary Laravel Package

Getting Started

Before installing, read composer.json in the repo. The description calls this a "Bundle", which in PHP terminology almost always means a Symfony bundle — verify the require block for symfony/* versus illuminate/* before assuming Laravel support. With 0 stars and 0 dependents there is no ecosystem evidence that Laravel is a supported target, so treat installation as an evaluation, not an adoption.

Practical first steps:

1. Install as a dev dependency only. This is documentation/observability tooling — it has no business in production runtime:

   composer require --dev mherrera05/data-dictionary
   

2. Check for package auto-discovery. If there's no extra.laravel.providers entry, you'll need to register the service provider manually in config/app.php (or bootstrap/providers.php on Laravel 11+). If the package only ships a Symfony Bundle class and a DependencyInjection extension, stop here — see the fallback below.
3. Look at the service that performs introspection first, not the formatter. The valuable part of any data-dictionary package is the schema-reading layer; the output layer (markdown/HTML/JSON) is trivial to replace. Find the class that queries information_schema or uses Doctrine's SchemaManager.
4. First use case: point it at a local database and generate a column-level listing for one or two core tables — name, type, nullable, default, indexes, foreign keys. Dump that into an internal docs page or the repo's docs/database.md.

If the package turns out to be Symfony-only, the equivalent in Laravel 10/11 is a handful of lines and worth doing yourself:

$tables = Schema::getTables();
$columns = Schema::getColumns('orders');
$indexes = Schema::getIndexes('orders');
$fks     = Schema::getForeignKeys('orders');

That is roughly the entire feature surface a package like this provides, which informs how much you should invest in making it work.

Implementation Patterns

Generate as a build artifact, never at request time. Schema introspection issues multiple metadata queries per table; running it in a controller or a view composer will tank response times on databases with hundreds of tables. Wrap it in an Artisan command (or a queued job) and treat the output like compiled assets:

// app/Console/Commands/GenerateDataDictionary.php
public function handle(DataDictionary $dictionary): int
{
    $output = $dictionary->forConnection(config('database.default'))
        ->except(['migrations', 'jobs', 'failed_jobs', 'sessions', 'telescope_*'])
        ->toMarkdown();

    File::put(base_path('docs/database.md'), $output);

    return self::SUCCESS;
}

Wrap the package behind your own interface. Given the maintenance risk, don't let mherrera05/data-dictionary types leak into your application code. Define a SchemaDictionary contract in your app and put the package behind one adapter class. Swapping to Schema::getColumns() later becomes a one-file change.

CI schema-drift detection. Generate the dictionary on a schedule (or per-PR against a freshly migrated database) and diff it. A non-empty diff on a PR that doesn't touch migrations is a useful signal that someone changed the DB by hand. Pair this with a migrate:fresh + generate step so the dictionary always reflects migrations rather than whatever is in a long-lived dev database.

Documentation for onboarding. The highest-value use is a docs/database.md regenerated per release. It answers the question every new hire asks — "what's in orders and what references it?" — without granting them a database client. Commit it, or publish it to your internal wiki in CI.

Combine with migrations for a two-way view. Migrations describe intent; the dictionary describes current state. If they diverge, one of them is lying. Reviewing the generated dictionary alongside a migration in a PR is a cheap sanity check on column types, nullability, and index coverage.

Filter aggressively. A raw dump of an app database is dominated by framework noise. Exclude migrations, jobs, failed_jobs, sessions, cache*, telescope_*, pulse_*, and any log tables — otherwise the useful 15 tables are buried under 20 irrelevant ones.

Gotchas and Tips

• Zero adoption is the headline risk. No stars, no dependents, no issue activity. Pin an exact version in composer.json, or fork it into packages/ and reference it via a path repository. If the introspection logic is under ~300 lines, copying it into your app is lower risk than depending on it.
• "Bundle" is a real compatibility question. Confirm Laravel support before writing code against it. A Symfony bundle expecting symfony/dependency-injection and Doctrine's doctrine/dbal will not wire into Laravel's container; you'd be using it as a library, not an integration, if at all.
• Single-connection assumption. Most small introspection packages read the default connection only. Multi-tenant or read/write-split setups usually need explicit per-connection handling — check whether forConnection() (or equivalent) actually exists before designing around it.
• Naive introspection misses things. Views, materialized views, enums/check constraints, generated/virtual columns, composite primary keys, partial indexes, and column comments are commonly omitted. Cross-check the output against SHOW CREATE TABLE orders or \d+ orders on a table you know well before trusting it on 200 tables.
• Credentials and exposure. Run against a local or CI database, never a production replica. Generated output leaks table names, column names, and comments — if you publish it, keep it internal.
• Stale output is worse than none. A dictionary that silently stopped regenerating six months ago will actively mislead people. If you generate it in CI, fail the build when the regeneration produces a diff that wasn't committed.
• Debug at the data layer, not the formatter. When output looks wrong, dump the raw introspection array first and compare to information_schema directly. Formatting bugs are obvious; missing columns usually mean the introspection query filtered them out.
• Extension points are likely formatter-level. If the package exposes an output/rendering interface, that's the cheap place to customize (add ERD links, group by domain). If everything is one monolithic class, don't fight it — extract the information_schema query and write your own renderer.
• Budget the decision. Give this a two-hour spike: install, introspect one connection, produce markdown. If that doesn't work cleanly, Schema::getTables() / getColumns() / getIndexes() / getForeignKeys() gives you the same result with zero dependency risk.