refactor: Graph analysis - unit testing

[elliott-with-the-longest-name-on-github]

The first of what I hope will be a long line of PRs leading up to 1.0 that focus on refactoring code to add unit tests and remove integration tests. Our test suites are starting to drag on to infinity, making merging PRs quickly a bit of a chore. Unfortunately, in this case, we haven't been able to remove any integration tests, but I think the unit tests do a much better job of covering all cases in a clean and readable way (that doesn't abuse TypeScript like we used to!).

We can't remove the integration tests because there's not really a great way to unit test our dependency on Vite and Rollup's module graph implementations. Sure, we could do some dumb and labor-intensive mock of their implementations, but that wouldn't really give us any benefits. We should continue to rely on the integration tests to see how this feature interacts with the real Rollup/Vite environment during dev and build.

Just a note: The graph analysis stuff is pretty self-contained and doesn't really feel at home in a utils.js file, so I moved it to its own folder to separate it and its types from the rest of the project.

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

[changeset-bot]

🦋 Changeset detected

Latest commit: 6a7e304

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

[Conduitry]

I don't think this warrants a changeset. There are (or at least there should be) no user-visible changes.

[elliott-with-the-longest-name-on-github]

I don't have a strong opinion here. There's a pretty contentious issue on the semver GitHub debating whether refractors are patches. I tend to fall on the "Don't release a refactor by itself, but include it in the patch notes because you did change the code" camp.

[benmccann]

yeah, it's an issue we've debated in the past. My personal opinion is basically the same as @tcc-sejohnson's because if the reactor breaks something it's way easier to track down the issue when the change is in the changelog. And I think prefixing it with [chore] as done here means people can easily ignore it when reading the changelog