In there @rose pointed out that the de-structured approach of jobs/commands per file scale better. One thing we have found is that, at scale, we use YAML aliases (what has been called anchors here) extensively for sharing param config across command jobs and sometimes across multiple commands. This is because in non-trivial orbs, threading params happens more often than not.
We can also imagine maybe wanting to share param config across orbs in the future, even (we have a mono repo). We’re considering looking at YAML templating tools to pre-process but so far nothing has been obviously lightweight enough to justify the overhead, that we’ve found.
We really need to support top-level parameters, so that a lot of this parameter config-sharing isn’t necessary, IMO—so I think you should throw your weight behind that idea @jasonkuhrt.
I totally agree that threading parameters should happen a lot in a large orb—it’s a powerful pattern, to, for example, provide jobs and commands that provide the same functionality, in which case you obviously need to pass down all the same parameters from the job to the command.
Does it feel like that feature would meet the needs you’re describing here? Or would something additional to that be necessary?
Top level params for job-to-command threading would cover a large % of our use-cases! I think it’s the right trade off to then adopt breaking config across files. Or at least a great step forward.