Which option should have the precedence? loose is set directly in the plugin, but assumption is the new modern option.

I think loose should be prioritized. We can use api.assumption("setClassMethods"); as default value for loose. So loose: false can not be overridden by api.assumption("setClassMethods");.

Do we want some kind of warning somewhere if both are specified?

Actually, can we flip this? Have api.assumption return undefined unless is explicitly specified, then default to loose:

api.assumption("setClassMethods") ?? options.loose

I think the assumption should be the highest priority, and we fall back to the old loose flag if the assumption isn't set.

The rationale for giving precedence to loose is that, even if it's "older", it's closer to the plugin:

{
  "assumptions": {
    "noDocumentAll": false
  },
  "plugins": [
    "@babel/proposal-nullish-coalescing-operator",
    ["@babel/proposal-optional-chaining", { "loose": true }]
  ]
}

I think that the most intuitive thing would be to respect loose for @babel/proposal-optional-chaining (and thus output == null), because it's explicitly passed to that specific plugin.

We can deprecate loose option in Babel 8 and rename loose in optional chaining to noDocumentAll. Otherwise it is unclear for users that loose is actually meant to override the noDocumentAll assumption.

So the question is if the top level thing (assumptions) should override the one closer to a plugin.. well either way we should notify the user somehow right? We don't want to suggest that both should be on right?

IMO @JLHwung In that case, it should go:~~

Half of the goal of the assumptions RFC is to centralise this kind of option rather than keeping it per-plugin, since (especially with class plugins) they have big cross-plugin implications.

I agree that loose is "closer" to the plugin, but the assumptions list is highly specific to transformer output. So I see it as being the higher precedence item.

Plus, I can see toggling certain assumptions on/off and using loose at the same time. This would allow devs to override some of the parts of loose, eg enabling classCallCheck while otherwise outputting loose code.

For backward compatibility to Babel < 7.13, we should check if api.assumption is available.

It has been handled in https://github.com/babel/babel/pull/12219/files#diff-876e2533ff9db5901b423e389d5aee5275594e79da63f0cdc14c8ce62f90b468R31