Don't hard-code migration names in PHP

Just a re-roll, the patch was not applying anymore for me. No changes except removed some unused use statements

Thanks for the CommercePrice.php suggestion in #16. I found that "fraction_digits" wasn't set on any of my prices. It looks like this is created in other commerce_migrate components but it seems it was left out here. This sets a value by looking up the currency settings.

The last CommercePrice fix caused one of the exception tests to fail because of the fix. This updates the test to handle a new exception.

I convert patch #17 to an MR. The changes after that are in 🐛 Throw SkipRowException in CommercePrice process plugin when there is no currency_code Needs review .

It does not appear to be possible to override the field plugins with custom config.

It has been a while, but is hook_migration_plugins_alter() not suitable?

There is a different fix for much of this at #3202219-11: MigrateField plugin commerce_customer_profile_reference prevents use of custom profile migration → which is simpler and more akin to what was done in core.

Why not use that method?

I keep returning to this wondering what I am missing. I don't see how disabling the field plugins is not a good idea. This means that other entities that use those fields will not migrate properly.

Make a copy of the commerce1_profile.yml and/or commerce1_order_item.yml files to local config and rename them and run them

I would expect that to fail for most migrations and any that requires fields. The process pipelines will not be prepared correctly because, as you know, that happens at run time. If one is working in run time the migrations can be altered by using hook_migration_plugins_alter. Commerce Migrate uses that hook a lot.

Or you can use migrate-upgrade to configure the migrations and then store them in config. In this case, they can be edited and part of your repository.

Convince me otherwise but I think this is a won't fix.