Correct me if I'm wrong but it looks like this is actually a breaking change. I've looked into the new-config fixture and it only has such .changeset/config.json:

{
  "changelog": false,
  "commit": true
}

I think the point of this PR was only to initialize the .changeset/config.json with the new value but not to change what it defaults to when it is not explicitly given etc.

I think the point of this PR was only to initialize the .changeset/config.json with the new value but not to change what it defaults to when it is not explicitly given etc.

What's the difference there?

@Andarist Happy to make changes here as necessary but I didn't quite understand your point.

The problem with the current solution is that if somebody already has a config like:

{
  "changelog": false,
  "commit": true
}

then with this change Changesets would start using main as their baseBranch and thus it would change behavior, by potentially crashing because a main branch might not even exist in a given repository.

When initializing Changesets we write defaultBranch into the generated .changeset/config.json, even though it's not strictly required because that property has a default. But since we are outputting this property it can be changed somewhat safely because people who are already using Changesets are not running changesets init, they have already done that in the past.

I see, makes sense. So we need two separate objects, one like defaultWrittenConfig which sets the default values in a new config file and another defaultConfigValues that sets the values for configs that don't specify optional keys??

Ye, smth like that would work. Please only that because this is a monorepo we might have to implement this in a non-intuitive way. We don't want to break people who don't upgrade all of the transitive dependencies at once.

I think that the safest solution is to not touch defautlWrittenConfig at all (as weirdly as it might be) - and to just override this value before we actually write it in the config file.

I think that the safest solution is to not touch defautlWrittenConfig at all (as weirdly as it might be) - and to just override this value before we actually write it in the config file.

I agree, seems like the best solution here.

I would extract this to a variable on the top of the file, so the added comment could be added to that variable so it would be visible~ in a common place for both places that have been touched here.