The "null" migration destination plugin can't be used

> The null destination plugin is intended to throw errors and not meet requirements.

Is it for tests? If so, that should be in a test module, and with a clearer name too.

A dev/null destination plugin is useful for developing migrations, so the 'null' destination should be made usable -- I filed ✨ add a null destination Needs review because I hadn't realised this class existed in core.

My use case was that I was trying to understand how to get data from a source that was a large set of XML files, in structured folders. I wanted to check that my configuration of the Url and XML source plugins (from Migrate Plus module) was working, and to see how much custom code I would have to do. To do this, I needed to run the migration and see the data (with Migrate Devel module's debugging options for Drush). But I didn't want to have to set up a real destination -- partly because that would be extra work, and also because I'd then keep having to roll back to run the migration again, because the map would get saved. So a null destination was exactly what I need -- it allows the migration to be run, does nothing with the data, so you can run it over and over again while you develop iteratively.

I agree that there's a use case for a "null-ish" destination - I often use something like Gold's Noop extension of core's Null destination plugin from #11 above if I want to debug a process plugin on the CLI.

The Migrate Sandbox → module might be another option, but to me it makes sense to have the option of a destination plugin that permits debugging sources and processes without needing any destination configuration or resulting in local content output.

Anyway, I'm here to +1 the idea of making this destination a living thing, if that works!

+1 for me as well.

I have similar use cases as @joachim.

My first use case is developing a migration from D7 Scald (using the migrate_source_scald_atom source which is completely undocumented and drush migrate:fields-source not really a help) to D10 Media.

My second use case is migrating user memberships from D7 organic groups to D10 groups, but I can't migrate the organic groups to groups as well. So I have to write a custom source plugin which reads the membership relations from the D7 database together with the D10 group UUIDs which will be added in the D7 instance. It is a bit too complicated to explain why we can't migrate organic groups to groups, lets simply say there are too big structural changes and the customer decided to use the migration to implement organizational changes already existing in real-life as well.

For both use cases it is really helpful to have a destination which doesn't create any data in the site until the plugins and migrations are ready and the real destination plugins can be used.

It would be good to get approval from the maintainers for this.

AFAICT the work to do is:

- change the null plugin to be usable, by removing the requirements fail property
- add in a test module (new or existing) a source plugin 'fail_requirements' which has that property
- switch tests to use the new source plugin