-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: Graph analysis - unit testing #6727
Conversation
🦋 Changeset detectedLatest commit: 6a7e304 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
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 |
Co-authored-by: Ben McCann <322311+benmccann@users.noreply.github.com>
'@sveltejs/kit': patch | ||
--- | ||
|
||
[chore] Refactor graph analysis for better unit tests |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this warrants a changeset. There are (or at least there should be) no user-visible changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
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:
Tests
pnpm test
and lint the project withpnpm lint
andpnpm check
Changesets
pnpm changeset
and following the prompts. All changesets should bepatch
until SvelteKit 1.0