Skip to content

Commit

Permalink
Configure project to use local vite, find answer
Browse files Browse the repository at this point in the history
These changes helped me find the definitive source of the problem in
Vite 5.0.0-beta.8:

- "fix!: return 404 for resources requests outside the base path"
  vitejs/vite@40fd2d9
  vitejs/vite#5657
  vitejs/vite#5656
  https://vitejs.dev/guide/migration.html#advanced

- Related:
  vuejs/vitepress#3239
  sveltejs/kit#2958

Of course, this is effectively a bug fix for Vite, pointing at a bug in
Vitest. Vite is now more strict about enforcing the Public Base Path,
and Vitest needs to propagate config.base somehow:

- https://vitejs.dev/config/shared-options.html#base
- https://vitejs.dev/guide/build.html#public-base-path

I'll explain the workaround in the next commit. What follows describes
how my methodology to pinpoint the problem evolved and concluded.

---

Adding the vite/packages/vite as a "file:" dependency and adding its
directory as part of the workspace proved challenging. The TypeScript
compiler (`tsc`) kept erroring out on the `tsc --emitDeclarationOnly
--outDir temp/node -p src/node` step of the build.

It took a few tries to realize that I needed to remove vite/node_modules
before every "pnpm build" in vite/. Somehow some stale artifacts were
poisoning subsequent runs.

That left the problem of running `pnpm i` in this project, which would
still try to rebuild vite/packages/vite and choke on the TypeScript.

After skimming vite/README.md, I realized I could try adding
vite/packages/vite as a "link:" dependency instead of a "file:"
dependency. I also learned I could use pnpm.overrides in package.json to
ensure other packages used this local version. I kept vitest/packages/*
in the workspace to make sure they used this linked version of
vite/packages/vite.

After that, I could now reliably build the two local packages, and have
the local vitest use the local vite.

Each time in the ../vite repository, I would:

```sh
rm -rf packages/vite/node_modules
git reset --hard <tag or commit>
pnpm i --frozen-lockfile
pnpm build
```

Then I'd go back to this repository and:

```sh
pnpm i
pnpm test
```

And here's the results of my bisection (I didn't actually use `git
bisect`, but followed the same essential process):

```text
v5.0.0-beta.12 FAIL
v5.0.0-beta.6  OK
v5.0.0-beta.9  FAIL
v5.0.0-beta.7  OK
v5.0.0-beta.8  FAIL
```text

Once I had my culprit, I went back into ../vite and ran:

```sh
gitk v5.0.0-beta.7..v5.0.0-beta.8
```

And once I did that, I could see the the commit immediately after
v5.0.0-beta.7 affected base path handling. So I repeated the process,
setting `<tag or commit>` in ../vite to
40fd2d9bf4073420e6c334f48dc3b63558b688ce. Indeed, this build failed,
confirming that commit as the culprit.
  • Loading branch information
mbland committed Dec 6, 2023
1 parent 52783ac commit 3676521
Show file tree
Hide file tree
Showing 4 changed files with 1,216 additions and 101 deletions.
1 change: 0 additions & 1 deletion .npmrc
@@ -1,3 +1,2 @@
auto-install-peers=false
prefer-frozen-lockfile=false
prefer-workspace-packages=true
9 changes: 7 additions & 2 deletions package.json
Expand Up @@ -12,8 +12,13 @@
},
"devDependencies": {
"@vitest/browser": "file:../vitest/packages/browser",
"vite": "4.5.1",
"vite": "link:../vite/packages/vite",
"vitest": "file:../vitest/packages/vitest",
"webdriverio": "^8.24.6"
"webdriverio": "8.24.6"
},
"pnpm": {
"overrides": {
"vite": "$vite"
}
}
}

0 comments on commit 3676521

Please sign in to comment.