- Does rikudou/doctrine-plural-naming work with Laravel Eloquent?
- No. This is a Doctrine ORM naming strategy, not an Eloquent feature, and it has no service provider, facade, config publishing, or Artisan commands. Eloquent already pluralizes table names on its own, so the package cannot influence Eloquent models. The legitimate Laravel use case is an application running Doctrine through a package such as laravel-doctrine/orm.
- How do I install and register rikudou/doctrine-plural-naming?
- Install it with Composer using composer require rikudou/doctrine-plural-naming. Then register the naming strategy during EntityManager bootstrap by calling setNamingStrategy with the package class, or set the equivalent key in your DoctrineBundle configuration. There is no Laravel auto-discovery surface, so all wiring happens in your Doctrine setup. Confirm the bootstrap hook documented for your pinned Doctrine version still exists before relying on it.
- Which Laravel versions does this package support?
- Laravel version support is the wrong axis here, because the package is not a Laravel package and does not depend on the framework. What matters is the Doctrine DBAL and ORM version it declares and whether that intersects your application lockfile. The naming-strategy API has moved across DBAL 2 and 3 and ORM 2.x and 3.x, so a version mismatch can mean the strategy registers but silently does nothing. Pin the package explicitly and check its declared Doctrine constraints before adoption.
- How does it handle irregular nouns such as person, status, or category?
- The package overview states it is built on the Doctrine Inflector component, which handles irregular and uncountable nouns according to its own rules. In practice that means Category becomes categories and Person becomes people if the inflector's dictionary covers them, while edge cases like status can vary. Confirm that doctrine/inflector is an explicit dependency and at what constraint, rather than an implicit transitive one. Add a regression test covering your organization's actual entity vocabulary plus one irregular and one compound noun.
- Do I still need @Table annotations after enabling the strategy?
- For new entities whose class names pluralize correctly, the strategy removes the repetitive @Table(name: ...) annotation. You should still keep explicit table names where the generated plural is wrong, where a legacy schema name must be preserved, or where the table is a reserved word. A practical pattern is to pin existing entities with explicit names so the strategy becomes a no-op for them, and let only new entities inherit the plural default.
- Does the naming strategy affect join tables and sequences?
- The scope of a Doctrine naming strategy is narrow, and the documented behavior here centers on converting entity class names to table names through one method. Join tables and sequences may follow separate naming paths or be defined explicitly, which is exactly where double-pluralization bugs tend to appear. Do not assume coverage. Prototype against a schema containing join tables and reserved words, then diff the generated DDL against an expected naming set before committing.
- Is this package safe to use in production?
- The delivered behavior is a single small method, but the dependency has no stars, no dependents, and a single author, so there is no downstream usage acting as a proxy for edge-case correctness. The main production risk is a mis-pluralized table name that fails at query time rather than at boot, hiding until a rare code path or report runs. Because the logic is small and a pure function, owning roughly forty lines outright or vendoring it with a test is a reasonable alternative to depending on it. Removal cost is low, which is its most favorable risk characteristic.
- Can I adopt it on an existing database without renaming tables?
- Not directly. Retroactive adoption means every table, foreign key, index, and raw SQL reference must follow the new plural names, which is a dedicated schema project rather than a dependency swap. The realistic sequence is incremental: give existing entities explicit table names so the strategy is a no-op, then let new entities inherit the plural default. That turns a risky cutover into a low-risk default for future work.
- How do I test the Doctrine naming strategy?
- The naming strategy is a pure function, so you can instantiate it and assert its class-to-table output without a database connection. Cover your real entity vocabulary, at least one irregular noun, and one compound or multi-word noun. Also assert that no annotation-driven name is unexpectedly overridden. This test is cheap and is the best protection against a late-surfacing query failure.
- What alternatives exist to rikudou/doctrine-plural-naming?
- You can use Doctrine's built-in naming strategies, such as the underscore or default strategies, combined with explicit @Table annotations where plural names are required. You can also implement a small custom naming strategy yourself, since the relevant behavior is limited to one method. For Eloquent-only Laravel services, enforce plural table names through migration conventions and code review instead of introducing a naming strategy at all.