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.

[AlemTuzlak]

To be honest I assumed it isn't, I also noticed that the styles don't get bundled properly in production with my fix and locally there's a FOUC before it loads up

[AlemTuzlak]

After a bit more investigation it seems that when @vanilla-extract/css is added into optimizeDeps include in the vite config the horrible FOUC goes away which was not the case before when it was a part of the repo, not sure if this is a bug with vanilla or just a vite thing though

[ghost]

At @AlemTuzlak did you end up getting a solution you were happy with? I am trying to migrate a styled-components monorepo (also using pnpm and turbo) to vanilla-extract

[AlemTuzlak]

Unfortunately not @j-mcfarlane this has kind of completely frozen our whole migration process and we're majorly blocked. Hoping this gets resolved soon, but it's been like a month so not as hopeful 😅

[ghost]

@AlemTuzlak I have been in the same boat, experimented with using panda-css, linaria, pigment and now vanilla-extract. Only thing ive gotten to work is tailwind - however im not a big fan.

[AlemTuzlak]

I personally only use tailwind, but our client uses vanilla, so we wanted to extract half the codebase into reusable shared pieces, but vanilla stopped us dead in our tracks.

I don't have the capacity to sit down and debug this, unfortunately, so I'm hoping the maintainers will get it sorted, shouldn't be that hard with a repro I hope

[askoufis]

@AlemTuzlak Sorry for taking so long to get to this. I can't reproduce your error exactly. Running your reproduction, I see these errors instead:

Error: No route matches URL "/Users/askoufis/code/vanilla-extract-css/issues/1494/vanilla-extract-issue/packages/ui/css/global.css.ts.vanilla.css"
Error: No route matches URL "/Users/askoufis/code/vanilla-extract-css/issues/1494/vanilla-extract-issue/packages/ui/css/_global.css.ts.vanilla.css"

What's interesting is that the CSS loads just fine.

Just as a side note, in future it would be greatly appreciated if your reproduction was much more minimal. It seems like you ripped out some relevant parts of a production app and put them in a repo, which is a good start, but there were many dependencies that are unused and not helpful when diagnosing issues.

Additionally, it would've be nice to mention that your app uses Remix + Hono. I spent some time setting up a Remix application that matched your monorepo setup without hono, and it works fine. Adding react-router-hono-server and its dev server brings back the above errors. I have my own reproduction in a repo if you would like to see it.

I'm not saying that react-router-hono-server is the culprit, VE could be doing the wrong thing here.