I don't have a reliable reproduction yet as it's EOD and the setup is rather complex so I'll try to put one together but I've debugged it deep enough to give you a basic idea of what's going on.
I've played around in the vanilla-extract-vite-plugin.cjs.dev.js file that comes in the dist of the latest vanilla extract package and I've found the root cause of the issue, before I go into that, first a bit of context.
We have a monorepo setup where we have apps under /apps/external/<appname> and then we have packages under packages/<packagename> . I decided to move vanilla extract styles out of the app directly into packages/ui and what I've noticed is that it crashes and it complains it can't find the file with the following path:
C:\Users\Alem Tuzlak\projects\site-next\apps\external\marketing-website\@id\C:\Users\Alem Tuzlak\projects\site-next\packages\ui\css\_global.css.ts.vanilla.css
After a bit of debugging I've added this code:
const getAbsoluteId = filePath => {
let resolvedId = filePath;
//console.log("resolved initial Id",resolvedId);
if (filePath.startsWith(config.root) ||
// In monorepos the absolute path will be outside of config.root, so we check that they have the same root on the file system
// Paths from vite are always normalized, so we have to use the posix path separator
path__default["default"].isAbsolute(filePath) && filePath.split(path__default["default"].posix.sep)[1] === config.root.split(path__default["default"].posix.sep)[1]) {
resolvedId = filePath;
//console.log("if", resolvedId)
} else {
// In SSR mode we can have paths like /app/styles.css.ts
resolvedId = path__default["default"].join(config.root, filePath);
+ if(resolvedId.includes("@id")){
+ console.log(resolvedId, config.root, filePath )
+ resolvedId = resolvedId.split("@id\\")[1]
+ }
}
return integration.normalizePath(resolvedId);
};
inside of the vite plugin and the issue went away. It goes into the else statement here and because the filePath param provided to the function starts with an @id for some reason they both get fused together into an invalid URL which results in a crash on vanilla extract side due to trying to resolve an invalid path. I know that the above solution is not the most elegant one but it fixed the problem for me.
Describe the bug
I don't have a reliable reproduction yet as it's EOD and the setup is rather complex so I'll try to put one together but I've debugged it deep enough to give you a basic idea of what's going on.
I've played around in the
vanilla-extract-vite-plugin.cjs.dev.js
file that comes in the dist of the latest vanilla extract package and I've found the root cause of the issue, before I go into that, first a bit of context.We have a monorepo setup where we have apps under
/apps/external/<appname>
and then we have packages underpackages/<packagename>
. I decided to move vanilla extract styles out of the app directly intopackages/ui
and what I've noticed is that it crashes and it complains it can't find the file with the following path:C:\Users\Alem Tuzlak\projects\site-next\apps\external\marketing-website\@id\C:\Users\Alem Tuzlak\projects\site-next\packages\ui\css\_global.css.ts.vanilla.css
After a bit of debugging I've added this code:
inside of the vite plugin and the issue went away. It goes into the else statement here and because the
filePath
param provided to the function starts with an@id
for some reason they both get fused together into an invalid URL which results in a crash on vanilla extract side due to trying to resolve an invalid path. I know that the above solution is not the most elegant one but it fixed the problem for me.Reproduction
https://github.com/AlemTuzlak/vanilla-extract-issue
System Info
Used Package Manager
pnpm
Logs
No response
Validations