Allow to configure a default simulator instead of always using --target on cordova run

[igorsantos07]

Feature Request

Motivation Behind Feature

The current default, when npx cordova run ios is executed without a plugged device, is to get the latest iPhone on the available list of simulators (code). I'm not sure why this decision was taken - since it usually ends up being the latest, but also the largest one and the "easiest to have a good experience", let's say.

thanks Norman for the help figuring that out on Slack :)

That said, it's suboptimal to either force the developer to always specify a long and complex option (since device identifiers are never small), in case the latest and largest isn't the best for them.

Feature Description

My suggestion is to either have it read from a CLI variable (e.g. CORDOVA_DEFAULT_IOS_TARGET) or some other setting baked into the user or project config. The CLI variable might be more suitable since different devs might have different preferences among the same team, but a project-wide config could be useful as well, although I'm not sure where that would go (I'm kinda noob about the Cordova inner details).

That said, since I checked the code to see what goes on, I think I'm able to code whatever is agreed upon here, if this feature seems to makes sense :)

Alternatives or Workarounds

Just repeating the current --target option with a long string, or coding yourself a bash alias, which feels out of the workflow, may be forgotten by the user if they only run the application every now and then, and is not exactly obvious for newcomers on the team.

[breautek]

Most of our "settings" would belong in config.xml but given this is more of a developer/build config, rather than an app config, an environment variable might be the way to go...

If we do use an environment variable, I think it's important to make a distinct variable per platform, like your suggested CORDOVA_DEFAULT_IOS_TARGET.

What you could do is maybe prepare a small document or some blurb of text describing what you plan to implement behaviour wise and subscribe/write to our Dev Mailing List with your intent. This will put more visibility among cordova contributors as GH notifications can be a bit noisy. (Just know the mailing list is for discussions regarding development & management of the cordova project only) It will probably be important to limit that scope to behaviour rather than code (code review is much easier on a PR) but what I'd probably recommend is something like:

1. If --target is present, then set target to --target value.
2. Else if CORDOVA_DEFAULT_IOS_TARGET exists, then set target to CORDOVA_DEFAULT_IOS_TARGET value
3. else; fallback to getDefaultSim() (or whatever the method is called)

I'm not very familiar with the part of code that handles the --target... But if the code is primarily in the platform (e.g. cordova-ios, then it's safe to hard-code CORDOVA_DEFAULT_IOS_TARGET environment variable lookup), otherwise you might have to incorporate the flow of choosing CORDOVA_DEFAULT_IOS_TARGET over some other platform target.

Give 48-72 hours to let people object to your plans. If there are any objections the mailing thread is Apache official way to resolve those kinds of disputes. And if there is an agreement (either explicitly or lazily by silence) then a PR could be created. This might save time building a PR that won't get accepted without drastic changes.