I think the top-left of the table has incorrect semantics. I think that if both files exist, workflow_settings.yaml should not contain a version. Otherwise things get way too confusing.

I think the top-left of the table has incorrect semantics. I think that if both files exist, workflow_settings.yaml should not contain a version. Otherwise things get way too confusing.

This issue with that in the CLI is that compilation isn't stateless, so we don't delete package.json after an install. So the first time installing works if there's dataformCoreVersion in workflow settings, but then subsequent installs will fail. From playing around with it, doing this seems to work just fine!

A workaround could be making it stateless, and updating the package manager to pnpm instead.

Let's decide on this in the UX review though, to avoid doing work that might not be needed.

OK, but we did already discuss this point!

OK, but we did already discuss this point!

In closed source, the Dataform Core version can be specified in either the package.json or the workflow_settings.yaml file.

It's true - but it's a pretty terrible UX when using it in practice.

In any case, the code fix if we do decide to do this is trivial.

OK - I'll say:

1. The UX nastiness is pretty resolvable. For one, it's a once-off thing (when migrating from workflow_settings.yaml to package.json). But if even that is too much, we can always make the CLI help you out with that migration.
2. Even if we do want to allow the version to be configured in two places, I would strongly argue that the preferred location should be package.json, not least because that's what all other NPM tooling would actually look at.

I would strongly argue that the preferred location should be package.json

I agree with this, extending it even to be the only location that open source packages configure versions - it's a bit weird having two ways of doing things.

once-off thing

I'm not sure that's true, because it's fairly common to run the Dataform CLI as part of CI/CD in a GitHub action from PRs - which gets run on the version of code on Google Cloud.

I'll have a think about the different user journeys, but atm this is the most versatile option!

But GCP should follow the same logic: i.e. if both files provide versions, it should throw. Therefore: in all environments, either you are setting it in one place or the other, but never both.