Causer morphs use bigint IDs, excluding UUID/ULID-keyed authenticatables

[jfrosorio]

Problem

The published migration defines the polymorphic causer columns with $table->morphs('causer', 'causer'), which creates causer_id as BIGINT UNSIGNED. Any authenticatable model using string primary keys — e.g. Laravel's HasUuids / HasUlids — cannot be attached as a causer: inserting a UUID/ULID into the bigint column fails (or silently mangles the key, depending on the driver/strictness).

The rest of the package is already model-agnostic: the middleware duck-types the authenticated model (method_exists($user, 'apiLogs')) and ApiLog::causer() is an unconstrained morphTo(), so this schema choice is the only thing tying causers to integer-keyed models.

Possible directions

1. Document the limitation in the README (minimum viable fix) and note that consumers can edit the published migration to uuidMorphs / ulidMorphs before running it.
2. Make the column type configurable at publish time — e.g. a config key ('morph_type' => 'int' | 'uuid' | 'ulid') read by the migration stub, the approach used by spatie/laravel-permission and similar packages.
3. Switch to string-based morphs (causer_id as VARCHAR) — works for both key types but breaks existing installs and loses index efficiency for integer keys, so it would need a major version + upgrade note.

Option 2 seems the best balance: existing installs are untouched (default stays morphs), and UUID/ULID apps opt in before publishing the migration.

Notes

• Since the migration is published as a stub (create_api_logs_table.php.stub), existing installs keep whatever they already ran — this only affects new publishes.
• Whatever direction is chosen, a test with a UUID-keyed fixture model would pin the behavior.