fix(fonts): config family types for inferred provider

[florian-lefebvre]

Changes

• There was a regression in feat(fonts): resolve config todos #13401 that made impossible to provide an object without a provider for a family
• This PR moves some things around to have types working properly

Testing

Updates the types tests

Docs

N/A

[changeset-bot]

⚠️ No Changeset found

Latest commit: 206febb

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[ematipico]

I would avoid a transform inside for our configuration. I used .transform in the past, which is the side effect of passing the transformed configuration to the integrations. This means they will have incorrect types, and they might be able to delete our defaults.

I experienced this inconvenience when I implemented i18n. I suggest injecting these defaults after the integrations run their hooks.

[florian-lefebvre]

Does that also mean the transforms don't run after updateConfig() is called? That would be bad indeed

[ematipico]

Yes. For v5, I wanted to break this, provide the unparsed/unvalidated configuration to the integrations, and eventually run Zod parsing afterward.

Unfortunately the architecture of Astro doesn't allow it, Astro requires the transformed/parsed values before it could run the integration hooks.

[florian-lefebvre]

I'm going to merge this anyways, because the issue is about how Astro validates some things currently. #13482 will address this problem