Skip to content

Add ignoreMigrations to the service provider. - #9

Open
MellieVT wants to merge 3 commits into
jonaspauleta:mainfrom
MellieVT:main
Open

Add ignoreMigrations to the service provider.#9
MellieVT wants to merge 3 commits into
jonaspauleta:mainfrom
MellieVT:main

Conversation

@MellieVT

@MellieVT MellieVT commented Aug 7, 2026

Copy link
Copy Markdown

Summary

Add ::ignoreMigrations() to ScoutPostgres\ScoutPostgresServiceProvider, because as-is there is no normal framework way to prevent this package from attempting to run its migrations outside of:

  • copy/pasting ScoutPostgres\ScoutPostgresServiceProvider to App\Providers\ScoutPostgresServiceProvider.
  • copying base config for publishing (the package short name will be scout-postgres, so it'll take priority).
  • putting ScoutPostgres\ScoutPostgresServiceProvider in composer's packages.dont-discover.

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing behaviour to change)
  • Documentation only
  • Refactor / internal cleanup (no behaviour change)

Checklist

  • Pest test added that fails before this change and passes after.
  • composer quality passes clean (Rector, Pint, PHPStan level max).
  • composer test passes locally against Postgres 14+.
  • CHANGELOG.md updated with an entry describing the change, using Keep a Changelog categories.
  • README / docblocks updated if public API changed.
  • Conventional Commit prefix on the PR title (feat:, fix:, docs:, …).

Notes for reviewers

Yes, you can just copy/paste the service provider, but this is the first package I've had to do this to in about 12 years of using Laravel. Is there a reason the service provider doesn't use ->publishesMigrations() for the migration like the current package guidance and instead runs them directly?

I'd have changed the package to use publishesMigrations, but that is a subtle backwards-compatibility break (by default the published migrations will have the current timestamp). I'd also have just extended the service provider too, but you've made them final. This is the route that seems the most future-proof, to be honest.

@MellieVT

MellieVT commented Aug 7, 2026

Copy link
Copy Markdown
Author

Also no test, because the current pest test merely checks the service provider boots, and you can't exactly run tests without the migration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant