Autotext Bundle Laravel Package

Getting Started

First, the reality check: meniam/autotext-bundle is a Symfony 6 bundle, not a Laravel package. There is no ServiceProvider, no facade, no config/autotext.php to publish, and no php artisan vendor:publish tag. A Laravel app will never boot the bundle's AutotextBundle class, so any bundle-level DI, tagging, or config/packages/autotext.yaml wiring is dead weight in your project.

That's fine — the useful part of a Symfony bundle is almost always the underlying library, and the bundle is a thin wrapper. Treat the install as two steps:

composer require meniam/autotext-bundle

Then read the vendor directory before writing any code, in this order:

1. vendor/meniam/autotext-bundle/composer.json — check whether the actual permutation logic lives in a separate meniam/autotext library that you could require alone.
2. vendor/meniam/autotext-bundle/DependencyInjection/ and Resources/config/services.yaml — this tells you the public service ID and the constructor signature. That's your real API.
3. vendor/meniam/autotext-bundle/README.md — for the expected input syntax (typically brace-and-pipe permutation, e.g. {Hello|Hi} {world|planet}).

Your first use case should be the lowest-risk one: generating varied but plausible filler text for seeders, factories, and demo data, where a wrong output costs you nothing.

// database/factories/PostFactory.php
'body' => fn () => app(TextPermutator::class)->permutate(
    '{Lorem|Ipsum|Dolor} {sit|amet} {consectetur|adipiscing}, {sed|ut} {do|eiusmod}.'
),

Implementation Patterns

Wrap it, don't call it directly. Because the package is Symfony-shaped, isolate it behind your own interface so the Symfony dependency stays in one file and you can swap it out later without touching call sites.

// app/Support/Text/Permutator.php
interface Permutator
{
    public function variants(string $template): array;
    public function one(string $template): string;
}

Register the adapter in a plain AppServiceProvider (singleton is safe — a text permutation service holds no request state):

$this->app->singleton(Permutator::class, fn () => new SymfonyBundlePermutator(
    new \Meniam\AutoText\...\Autotext(/* config array, see below */),
));

Pass config in by hand. Anything the bundle would have read from config/packages/autotext.yaml (dictionaries, default separator, casing rules) you must feed the constructor yourself — put it in config/autotext.php and config('autotext.*') it through the adapter. This is the single biggest integration step.

Use it where variety is the point, not where correctness is:

• A/B copy in mailables/notifications — generate N variants at authoring time, store the chosen variant ID on the send record, and report on it later. Never generate the variant at send time if you want reproducible analytics.
• Str::macro('permutate', ...) for Blade/tinker ergonomics.
• Queue jobs for anything combinatorial. Five slots with four options each is 1,024 strings; ten slots is a million. If you're generating "all" variants, always bound the count and throw on templates above your limit.

Persist and dedupe. In seeders, wrap in ->unique() on the collection and re-permutate on collision rather than assuming uniqueness — permutation output is not random, it's exhaustive, so duplicates appear predictably.

Gotchas and Tips

• The container will bite you if you app() the Symfony service class directly. Symfony services frequently take ContainerInterface, LoggerInterface (PSR vs Symfony), or tagged-iterator arguments. Laravel resolves none of that. Always construct via your adapter with explicit arguments.
• Zero stars, zero dependents, one release (Dec 2024). There is no community safety net, no Stack Overflow coverage, and no third-party battle testing. Pin the exact version in composer.json ("meniam/autotext-bundle": "1.0.0" style, not ^), review the source once, and write a handful of your own feature tests asserting the output shape you depend on. If the author changes the delimiter or returns a generator instead of an array, those tests are your alarm.
• Unicode/encoding. The author's ecosystem is largely Cyrillic-facing, so multibyte handling is probably good — but verify with your own alphabet. Test emoji, combining accents, and RTL strings through the pipeline; strlen assumptions inside the library will show up as truncated words.
• Escaping the delimiter. Ask what happens with a literal { or | in the source text (JSON snippets, formula docs, code samples). Expect no escape syntax; sanitise or bypass the permutator for those fields.
• Determinism for tests. If there's no seed option, variants() output order is the only stable thing you can assert against. Don't assert on one() — mock the Permutator interface in tests instead and keep the real thing for one integration test.
• Memory, not speed, is the limit. Materialising all permutations into an array is where this blows up. If the library exposes an iterator/generator, use it; if not, cap template complexity in a form request or validation rule before it reaches the service.
• Extension points: decorate, don't fork. Add post-processing (trimming, capitalisation fixes, profanity filtering) in your own decorator implementing the same Permutator interface. Forking a zero-star package means you own the merge forever.
• Debugging is plain PHP. dump()/dd() from Laravel work fine in your code; if you're stepping into the vendor classes, note that any dump() calls baked into the bundle rely on Symfony's VarDumper helpers which Laravel doesn't autoload the same way. Use Xdebug rather than editing vendor files.
• Exit criterion. If after a day of integration you're writing more glue than feature code, drop the bundle and use fakerphp/faker's randomElement over your own word lists, or spatie/laravel-* text helpers. For most Laravel apps the honest recommendation is: require the underlying library only, wrap it in ~40 lines, and skip the bundle entirely.