Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
TL;DR
This PR allows developers to specify whether their package should auto-discover all migrations in their package without having to specify individual file names.
Context – What problem does this solve?
For smaller packages with maybe a handful of migrations, calling
hasMigration
multiple times (or justhasMigrations
once) is trivial and non-invasive.However for larger packages, or for people using this tool in larger projects (e.g. registering composer modules in a large-scale production application), having to specify the name of every migration that is within a package or module becomes arduous and prone to mistakes
For example, newer developers will not necessarily always remember that each migration must be manually registered in a service provider (especially since Laravel's functionality is to auto-discover migrations).
Solution
This PR allows developers to choose whether or not their package "auto-discovers" its own migrations, by expanding the
Package
API with a newdiscoversMigrations
method.Developers and teams can now simply build a new package with as many migrations as they like without needing to remember to manually register the migration:
When this is called, we will assume this is the default and that any calls to
hasMigration
orhasMigrations
can safely be ignored. (If not, then in some scenarios, this would cause duplicate migrations and errors after publishing migrations and runningartisan migrate
).I've also updated the
hasMigrations
to calldiscoversMigrations
when no migration names are provided