[fix] allow any top-level keys in svelte config

[bluwy]

Fixes #2253

Allow any top-level keys to be added to the svelte config, essentially skipping validation for the top-level keys only.

Unrelated side note: I'm not sure why we're not using something like superstruct to handle validation. And if the spec of the svelte config should live here?

Before submitting the PR, please make sure you do the following

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpx changeset and following the prompts. All changesets should be patch until SvelteKit 1.0

[changeset-bot]

🦋 Changeset detected

Latest commit: 66fdaa8

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@sveltejs/kit	Patch

Not sure what this means? Click here to learn what changesets are.

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

[ignatiusmb]

Looks good! Just a couple of questions

[benmccann]

Unrelated side note: I'm not sure why we're not using something like superstruct to handle validation. And if the spec of the svelte config should live here?

I'd be happy to use superstruct or something similar. I hadn't seen that library and think we only coded it ourselves out of unfamiliarity with other options. I've heard other also ponder if we should have a package specifically for svelte config, but no one's really made a proposal or wanted to take on that work. I think it's something folks would be open to though since I have heard it before

[ignatiusmb]

I think misplacing kit options outside config.kit is pretty common and the hint might still be useful to have around for some people, perhaps we can still iterate over it even if keypath is config, but have a couple of ifs for it inside to skip them if it's not in config.kit.

[bluwy]

superstruct

Yeah, it would be nice to use that instead to also remove the need to maintain its tests. But I guess there's already an infrastructure setup for custom validation so until some issue comes up with it then we could consider superstruct. I'd be happy to tackle that.

separate package for svelte config

It would be nice to have something like postcss-load-config but for svelte so it can also be used by vite-plugin-svelte and the language tools. I'm also not sure if vite-plugin-svelte should be polluting the top-level keys in svelte config either since there really isn't a clear spec for that (?). But it's a bit off-topic now :)

warn misplaced kit options

@ignatiusmb I'd be afraid that it would cause false positives for that. If one day a package decides to use a top-level key that's the same as config.kit.*, then it wouldn't work in kit even though it should.

[ignatiusmb]

I'd say the odds are pretty slim and we should not encourage packages, at least community-made, to directly use top-level config and instead put them under a name like kit does. I'm thinking we could at least warn them in the console or do a double-check using its value type or if the keys matches what we expected in the config. But, I guess we can discuss more when this is handled outside of kit, so this should do for now.

[ignatiusmb]

Thanks!

[benmccann]

Sure, feel free to send a PR for superstruct if you're interested

I agree that options should be under a namespace like kit