Overwriting framework-provided migrations

[brendt]

The auth component comes with a default migration for a User model. However, sometime a project might not want to use it. We need a way to disable/overwrite this migration. My first thought would be to allow users to add their own migration with the same name, which would get precedence.

[innocenzi]

@brendt My first thought would be to allow users to add their own migration with the same name, which would get precedence.

It should be possible to not run a specific migration at all (eg. an application that would want an ABAC authorization model instead of the built-in PBAC one)

[brendt]

True. Technically this can be solved with #338, although I wonder what a better approach would be.

We could also require specific files to be explicitly published before they are discovered (eg. framework provided migrations and controller routes). That's approaching the problem from the other way around.

[innocenzi]

@brendt although I wonder what a better approach would be

Honestly, the more I'm thinking about it, the more I believe the publishing model from Laravel is what makes more sense for migrations.

One downside would be that the base template would probably have a CreateMigrationsTable.php somewhere along the default files, but I think I'd rather have that than having to figure out how to customize stuff the way I want. That would also require #338 so migrations files built in Tempest could be ignored.

EDIT: just realized I read half your comment before posting mine lol. oops

[brendt]

It actually would be pretty trivial to add an attribute #[ShouldBePublished] that framework and third part code can add on any class they don't want to be discovered automatically 🤔

Just thinking out loud now. It would probably prevent a lot of confusion