Anonymize Bundle Laravel Package

Getting Started

nowo-tech/anonymize-bundle is a Symfony bundle (not Laravel-native), so the first decision is whether your project already runs Doctrine ORM. If you're in pure Eloquent territory, this package will not plug into php artisan db:seed or ModelFactory; you'd only benefit if you're already bridging Doctrine.

Assuming a Symfony/Doctrine project:

1. Install via Composer and register the bundle in config/bundles.php (Symfony Flex should prompt automatically; older Symfony versions require manual registration).
2. Look first at the bundle's Resources/config/ service definitions and its attribute class. The README is thin (low star count), so the source is your documentation. Confirm:
   • The exact attribute name and its constructor options (generator, locale, uniqueness, nullable behavior).
   • Whether there is a CLI command (typically bin/console nowo:anonymize:...) and what arguments it accepts (entity, batch size, dry-run, IDs).
3. First use case: point the bundle at a development copy of a production dump and anonymize the PII columns only — email, phone, first/last name, address, notes. Leave IDs, timestamps, foreign keys, and boolean flags untouched so relations and app logic still work.

Minimal first pass:

#[ORM\Entity]
class Customer
{
    #[ORM\Column] private string $email;
    #[Anonymize(generator: 'safeEmail')] // confirm exact option names
    public function getEmail(): string { /* ... */ }
}

Then run the bundle's console command against a scratch database, diff a sample of rows, and only after that wire it into CI or fixtures.

Implementation Patterns

1. Field-level annotation, not row-level rewriting. Treat the attribute as a per-column transform. This keeps you in control of which fields are PII and which are structurally load-bearing (foreign keys, enums, status flags).

2. Test fixture generation. In doctrine-fixtures or Foundry factories, let the bundle fill anonymized fields after flush()-style population. Pattern:

• Create realistic entities with real-looking data for dev.
• Run the anonymizer as a final pass so fixtures never contain the same PII twice.

3. Dump sanitization pipeline. The strongest day-to-day use is dev/staging refresh:

1. Restore a prod dump into a scratch DB.
2. Run the anonymizer command with a batch size (e.g., 1,000 rows) to avoid memory spikes.
3. Validate a sample against an allowlist of "should still be meaningful" fields.
4. Dump to the shared dev DB.

Wrap steps 1–4 in a shell script, not a service, so it stays reproducible.

4. Custom generators. Faker alone won't cover domain-specific fields (IBAN, license plates, national IDs). Register a custom generator service tagged appropriately and reference it from the attribute. This is the primary extension point — keep it stateless and deterministic when seeded.

5. Deterministic seeding for tests. If the bundle exposes a seed/configuration option, set it in config/packages/test/. Reproducible anonymization prevents snapshot-tests from churning on every CI run.

6. Selective / scoped runs. For large tables, anonymize by ID range or by entity class rather than "all rows." Pattern: a small wrapper command that loops tenants or ID windows, calls the bundle's service, and commits per batch.

7. Environment gating. Do not rely on the bundle to protect you. Add an explicit guard in your console command (e.g., refuse to run when kernel.environment === 'prod') so a mis-typed --env cannot mutate production PII.

Gotchas and Tips

• It's Symfony-only. This is the biggest practical issue for a Laravel developer: there is no Eloquent adapter, no Artisan command, and no service provider. You would need Doctrine in a Laravel app plus manual bundle wiring — realistic only for hybrid projects. Budget for that before adopting.

• Low project maturity. Two GitHub stars and few dependents means API surface and attribute names may shift. Pin the version, read the attribute class before trusting the README, and treat console command flags as "verify, don't assume."

• Uniqueness constraints are the #1 breakage. Faker's safeEmail/userName can collide on large tables with unique indexes. Use Faker's unique() (or the bundle's uniqueness option if supported) and seed consistently, otherwise the run dies mid-batch with a UniqueConstraintViolationException.

• Foreign keys and ordering. Anonymize child tables before parents where the schema requires it, or disable FK checks explicitly during the run. Silently failing FK constraints are easy to miss if you're not watching Doctrine's SQL log.

• Irreversible by design. There is no rollback. Always run against a scratch copy, and keep a pre-anonymization checksum or sample of N rows if you need to verify "what changed."

• Batch size matters more than you'd expect. Faker's generator and Doctrine's unit-of-work are both memory-hungry on large entities. Start at ~500–1,000, clear() the EntityManager between batches, and watch for the classic "memory leak from retained entities" smell.

• Don't anonymize primary keys or updated_at/created_at. Doing so breaks pagination, cursor-based sync, and downstream analytics that expect monotonic timestamps.

• JSON, binary, and encrypted columns almost never work out of the box. Faker returns strings; the DB expects jsonb or bytea. If the bundle doesn't expose a per-type generator hook, you'll need a custom post-processor — check whether the attribute supports a "value transformer" before assuming it does.

• Logging leakage. Doctrine SQL logging in dev can echo anonymized values into var/log. That's mostly fine, but if you're anonymizing because the data is sensitive, scrub or disable the logger for the run.

• Extension point to know: the generator registry. If the built-in Faker providers don't match your domain, a tagged custom generator service is the clean integration — do that instead of monkey-patching the command.

• Test isolation. If the bundle's command touches every entity, a test that seeds one entity will also touch the rest. Either scope by entity class or run against a fresh SQLite DB per test.