Issue with monorepo + vanilla extract

[AlemTuzlak]

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 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.

Reproduction

https://github.com/AlemTuzlak/vanilla-extract-issue

System Info

System:
    OS: Windows 11 10.0.22631
    CPU: (24) x64 12th Gen Intel(R) Core(TM) i9-12900K
    Memory: 9.17 GB / 31.71 GB
  Binaries:
    Node: 20.16.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.21 - ~\AppData\Roaming\npm\yarn.CMD
    npm: 10.6.0 - C:\Program Files\nodejs\npm.CMD
    pnpm: 9.12.2 - ~\AppData\Roaming\npm\pnpm.CMD
  Browsers:
    Chrome: 130.0.6723.70
    Edge: Chromium (127.0.2651.74)
    Internet Explorer: 11.0.22621.3527

Used Package Manager

pnpm

Logs

No response

Validations

• [X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• [X] The provided reproduction is a minimal reproducible example of the bug.

[AlemTuzlak]

I've added a full repro of the issue!

[askoufis]

Thanks for the reproduction @AlemTuzlak. I'm unsure if your solution is the right way to fix this, but I'll dig into this when I get some more time.