-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
fix(vitest): invalidate setupFiles with extension-less path #6749
base: main
Are you sure you want to change the base?
fix(vitest): invalidate setupFiles with extension-less path #6749
Conversation
✅ Deploy Preview for vitest-dev ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
if (source === 'setup') { | ||
getWorkerState().moduleCache.delete(filepath) | ||
const resolved = await this.__vitest_executor.resolveUrl(filepath) |
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.
Shouldn't it be resolved here even without the extension?
resolved.setupFiles = toArray(resolved.setupFiles || []).map(file => |
This worked before without problems
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 imagine it's working for most of the case, but the issue was when it's extension-less relative path. For example, setupFiles: ['./setup.ts']
works but setupFiles: ['./setup']
fails, which was OP's repro.
Alternatively, we can use Vite server resolver during resolveConfig
or sometime later if we restructure a bit, but I thought there might be a reason not to bring that.
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 am saying that it shouldn't fail even without the extension
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, we should fix it for sure, but I don't think this was a regression and extension-less relative path has never been handled with proper invalidation. I'll think about the solution.
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.
In any way, I don't think the current fix in this PR is the correct one. In the very least it seems weird to me that it processes the same setup file in every test (which means it processes the same value multiple times). The setup file ID should be resolved already at the config stage. The resolvePath
in resolveConfig
is supposed to be able to resolve any JS paths even without an extension as far as I understand - why doesn't it? 🤔
Description
--no-isolate --no-file-parallelism
#6682Please don't delete this checklist! Before submitting the PR, please make sure you do the following:
pnpm-lock.yaml
unless you introduce a new test example.Tests
pnpm test:ci
.Documentation
pnpm run docs
command.Changesets
feat:
,fix:
,perf:
,docs:
, orchore:
.