Migrations are configuration entities. Why?
- They get the config entity query-ability
- They get the discovery and installation
- They get config overrides (this is used in the Drush runner)
- There might be a migrate builder with a UI
- They have no lifecycle - deleting a migration config entity through the API outside of uninstalling migrate_drupal does not really make sense. Config entities have lots of code to manage them through their life and migration uses none of this.
- They are never configured - either by the API or UI
- They pollute active configuration for no reason - there is no runtime requirement to access migrations - they exist for a use case that covers the 0.0000001% life of a site.
- They pollute config export - putting them into your site config git repo - does that make sense
- They pollute config import - they're only ever going to show here as an addition or deletion - just noise.
- They have the overhead of config schema for translating one thing - the label
- Config overrides are a double edge sword - there are many many things in a migration that make no sense to override
This issue would makeredundant - which is the reason I started this issue.
Remove use of ConfigStorage and ConfigEntityBase in the migration classes. Use a YAML file reader that is able to read migration YAML files from another location.
- Agree (fight)
- Decide to go ahead or not
User interface changes
Not as many as you would think