fix: resolve baseUrl / paths relative to the real path of the tsconfig#1080
Conversation
How to use the Graphite Merge QueueAdd the label merge to this PR to add it to the merge queue. You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has enabled the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. This stack of pull requests is managed by Graphite. Learn more about stacking. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1080 +/- ##
==========================================
+ Coverage 92.35% 92.42% +0.07%
==========================================
Files 21 21
Lines 4079 4104 +25
==========================================
+ Hits 3767 3793 +26
+ Misses 312 311 -1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Merging this PR will not alter performance
Comparing 
Footnotes
|
|
Can we merge this? |
This is an attempt to fix the Enterprise build issue due to to theme/app.css not being found. Claude suggests that it may be related to Vite 8's built-in `resolve.tsconfigPaths: true` not handling baseUrl-relative resolution reliably. I'm not positive that this will fix it, but it's a small change and it goes back to the way we did it before vite8, so it seems worth trying. It's hard to replicate locally, so this is probably the quickest way to validate it. For reference, the handling was updated in #11766. Running the front end with this plugin makes vite emit this: > The plugin "vite-tsconfig-paths" is detected. Vite now supports tsconfig paths resolution natively via the resolve.tsconfigPaths option. You can remove the plugin and set resolve.tsconfigPaths: true in your Vite config instead. However, there may still be some issues left to fix (e.g. vitejs/vite#21856 ; upstream PR to fix it oxc-project/oxc-resolver#1080) Claude's summary: Vite 8's built-in `resolve.tsconfigPaths: true` only handles `paths` mappings reliably; baseUrl-relative resolution is fragile in some environments (we hit it in enterprise's pnpm-driven prepack of OSS, where `themes/app.css` and similar bare imports failed to resolve). The pre-Vite-8 `vite-tsconfig-paths` plugin handled both. Re-add it with the same plugin position as before, and drop the built-in flag to avoid two resolvers disagreeing on edge cases. Drop the plugin again once the built-in handler matures.
3 participants
When a tsconfig extends another tsconfig through a symlinked path (common in pnpm workspaces where
node_modules/pkgis a symlink),baseUrlandpathswere computed relative to the symlink location instead of the real file location (vitejs/vite#21856).