Workflow fix - #111
Conversation
fileURLToPath() produced a plain Windows path (D:\...), which the ESM loader misread as the protocol 'vitest-environment-d:' when spawning forks workers. Passing an href file:// URL works on all platforms.
Vitest only treats the environment value as a path when it starts with '.' or '/'; absolute POSIX paths leaked a file:// scheme that crashed dependency detection, and Windows drive paths were misread as the protocol 'vitest-environment-d:'. Compute a './'-prefixed path relative to the config root instead, which works on every platform.
ConfigEnv does not expose the project root; Vitest defaults to the process cwd, which is where tests are always launched from.
The function form of defineConfig does not typecheck against Vitest's overloads; the root-relative environment path is computed eagerly instead, since tests always launch from the package directory.
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: dbeb388749
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| with: | ||
| path: lara-framework | ||
| fetch-depth: 0 | ||
| ref: ${{ github.event.pull_request.head.sha || github.sha }} |
There was a problem hiding this comment.
Checkout the same PR revision in both build jobs
On pull_request runs where the base branch contains commits absent from the PR head, this forces build-java to build the head commit, while the unchanged checkout in build-js uses the pull request's synthetic merge commit. The JS tests then consume Java binaries built from a different Lara revision, so integration failures can be missed or spurious failures can occur; both jobs should use the same revision.
Useful? React with 👍 / 👎.
| const root = process.cwd(); | ||
| const environmentPath = path | ||
| .relative(root, fileURLToPath(new URL("./weaverEnvironment.ts", import.meta.url))) |
There was a problem hiding this comment.
Derive the environment path from Vitest's actual root
When this exported config helper is used with a Vitest root different from process.cwd()—for example, vitest --root Lara-JS launched from the repository root—the generated path is relative to the process directory but Vitest resolves ./... against its configured project root. That produces a duplicated or otherwise incorrect path and prevents the custom environment from loading; the relative path must be based on the effective Vitest root.
Useful? React with 👍 / 👎.



No description provided.