Add support for Drush via command line only

Thank you for proposing this, but in this particular case I will mostly reject it.

The reason is that when I created this module, I wanted a clear separation from the Drupal's configuration folder. This is one major difference with Menu Export and Structure Sync modules. I wanted full control of the exported files, I wanted them to be seen in GIT easily from the start, to encourage the user to have them placed outside the Drupal root's directory and to leave the user the choice if they sync them or not. Also, these files are not configuration, so in my opinion they don't belong in the configuration directory just by their role.

Furthermore, the Quick Action Settings form values can always be overridden in settings.php. So, if GUI needs to be avoided in some cases for the exported path, it can always be done directly in settings.php.

The only part that I agree with, and actually considered it while I was working on the related issue was the --format option. This we can definitely add.

Closing this, with the mention that the --format option will be resolved in the related ticket.

Thanks for a fast answer, as always!

The reason is that when I created this module, I wanted a clear separation from the Drupal's configuration folder.

I do get your point about differentiating this module from other sort of similar modules, so from that perspective it does make sense.

I did try Menu Export originally, but it didn't seem to work with Drush... which was what attracted me to Migrate Menu. I somehow missed Structure Sync ... but it looks like it might be a better fit for my needs -- since I desire a pure Drush solution :)

And you're right, destination/source can always be overridden. Thanks for considering adding the format option, YAML is easier to scan!

Indeed, Menu Export did not have a Drush command, a major problem/inconvenience for me, but that and other reasons are the core of my decision to create my own module, including the configuration.

I didn't know about Structure Sync either, I actually discovered it after I finished the development stage of version 4, when I was doing research about "Similar modules and how are they different" for the module's page updates.

Still, both Menu Export and Structure Sync do have the configuration sync principle, which is why my module's core functionality needs to continue on the route it was born in (independence from config).

On the other hand, I'm glad to hear that Structure Sync fits your needs, they also seem to have more control over partial and full imports, which my module lacks.

Thanks!

It's really strange how we both missed Structure Sync ... maybe due to bad SEO? When you search for relevant menu export import modules, with something like "site:drupal.org export menu configuration" you get a few "it doesn't work" Structure Sync issues, but are mostly guided to other modules ...

I do understand why Menu Migration should stay on this route, to differentiate itself.

> ... Structure Sync [...] they also seem to have more control over partial and full imports, which my module lacks.

Actually, it's true that via the Structure Sync GUI you can select individual menu's, but not with Drush. That's a case of "Export All The Things" or nothing. So in that department Menu Migration has the lead :)

$ drush export:menus -h
Export menu links.

Global options:
-v|vv|vvv, --verbose Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug
-y, --yes            Auto-accept the default for all user prompts. Equivalent to --no-interaction.
-l, --uri=URI        A base URL for building links and selecting a multi-site. Defaults to https://default.
                     To see all global options, run `drush topic` and pick the first choice.

Aliases: em, export-menus

Yeah, it's very strange indeed, and I am trying to remember, but I'm not 100% sure. I know I was exploring the Project Browser at some point, and it could be that I found it there. But still, not sure. It could be long Google search or Project Browser.

Oh, I see. Well, each module with their pros and cons it seems.