[breaking] move packaging functionality into its own package

[dummdidumm]

Draft PR to move the package functionality out of SvelteKit. This makes the following decisions (all up for discussion):

• New package is called @sveltejs/package
• Package has its own CLI, svelte-package, svelte-kit package will be removed
• Minimal SvelteKit interop; kit.files.lib is used to set source if source is unset
• We don't call svelte-kit sync in this package because you can use it standalone, but the template will call it before calling the package command

TODOS:

• SvelteKit and this new package share some utility code around filesystem stuff and options parsing. How do we best share this, if at all? Should we create a private package in the monorepo and enhance the rollup config to inline it, so no visible changes to the outside? Sounds like the best solution to me
• How to deploy this as a new package? Changeset masterminds please help. Is it enough to create a changeset and the rest is taken care of?
• Adjust SvelteKit code: remove packaging, remove the config (error and tell to switch to this new package)

Please don't delete this checklist! 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
• [x] This message body should clearly illustrate what problems it solves.
• [ ] Ideally, include a test that fails without this PR but passes with it.

Tests

• [x] 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 pnpm changeset and following the prompts. All changesets should be patch until SvelteKit 1.0

[changeset-bot[bot]]

⚠️ No Changeset found

Latest commit: 6f1526ca14e07075ab0eba9090a7f8d075589ea3

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.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

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

[dummdidumm]

Tests for create-svelte are failing because the package isn't available yet on npm. The lint error is unrelated to this change, since the env PR the test needs sync to run first. So although CI is all red, this PR is actually passing it.

[Rich-Harris]

Did as much of the grunt work of updating this post-#5748 as possible. Since kit is no longer bundled, the @internal/shared package isn't really an option unless we were to actually publish it to npm. I think it's preferable to just copy the few utility functions kit and package have in common, unless we find ourselves using them in more places.

I think we should get rid of the exports and files options in favour of having people include the "exports" field in their package.json files, pointing at the src code, so that the generated pkg.exports has the same shape but points to the package directory. This would allow people to use packages in a monorepo without needing to constantly build them. The exports would be treated as entry points, and we'd follow all the imports from those entry points to figure out which files need to be included in the package, making files unnecessary.

I don't have a strong opinion about whether that should happen in this PR or a follow-up.

[dummdidumm]

I think we should merge this as-is and do the other stuff in follow-up PRs.