Open in Stackblitz

npm i https://pkg.pr.new/vite@19182

commit: fb54eaf

I personally prefer to not add special handling here and have it fixed in tsx instead. It looks like it's going to affect more modules that only sass-embedded, and also it's not clear to me why it's mangling the exports of .js files in node_modules.

The solution to the original issue referred to by this PR — Cannot read properties of undefined (reading 'initAsyncCompiler') — is simple:

Add to vite.config.ts:

    css: {
      preprocessorOptions: {
        scss: {
          api: 'legacy',
        },
      },
    },

The situation has just changed after Vite 7 release. As mentioned in migration guide in Vite 7 there is no way to use legacy or modern-compiler SCSS API.
We used modern-compiler API in our projects so we unable to upgrade to Vite 7 now.

There are already three PRs in Vite trying to fix this:

• fix(sass): replace default import with ESM module import #17880 - August 14, 2024, first one, created by me
• fix(css): avoid using default export from sass-embedded #19053 - December 23, 2024 @cod1r
• fix(css): workaround tsx esModule interop of sass-embedded import #19182 - January 11, 2025 (this one) by @hi-ogawa

All three PRs are almost identical :)

I know that the source of the problem probably the issue in tsx, but as I understand it might be quite hard to fix it and the issue .

My points to go ahead with such fix (maybe, we should change the PR a bit):

• I do not see any workarounds with Vite 7 if we want to use complex TypeScript configuration files. Right now we use tsx and it almost perfectly solves the problem. I tried Node.js type stripping with amaro import loader, Vite --configLoader option - but without success, tsx still seems to be the best solution for Vite + TypeScript configuration
• SASS default import is deprecated long time ago. Link to SASS code. So as understand we actually can just remove .default property access when importing SASS
• This fix seems to be quite simple and safe and can possibly make many Vite users happy :)

I am ready to provide any additional context or to create another PR with suggested changes if needed. @hi-ogawa, can we please proceed with this?

Just an update. I finally found a quite simple and reliable way to use complex TypeScript Vite configurations in our project.

Earlier before Vite 7 release we used --import=tsx Node flag when running Vite. It worked almost perfectly, but now I understand that this is not a quite reliable way to run Vite. And here comes this issue and PR with SASS.

Now we removed --import-tsx from our Node environment and run Vite in "normal" way.

Instead, we now use tsx ESM Register API. It works like a charm without any errors and, because we use import statement - type information doesn't get lost.

So finally, I think I am done with this approach.

I am actually now not sure if we should fix this "SASS import" issue. Instead, maybe we can make Vite a bit better when using it with complex TypeScript configurations (#5370)? I know, there is now a --configLoader runner option in Vite 7, but it seems to be not working with dynamic imports in config files.

So finally here are couple of things to consider: maybe we can just document how to use tsx with Vite TypeScript configurations or implement --configLoader tsx Vite option?

I'm currently experiencing an issue when using Vite+Vue+Cypress@15.0.0+TypeScript that can be fixed by this PR's changes (I've applied these change as patch, and it works well afterward).

Since Cypress version 15.0.0, they've switched to using TSX under the hood, and we are having difficulty using Vite as file preprocessor ever since (if we have sass or sass-embedded in our packages).

Here's the issue on Cypress repo: cypress-io/cypress#32362

Can these PR be included in a (near) future version of Vite?

I'm one of Quasar framework maintainers, this is a blocker for supporting Cypress 15 in our Cypress integration package

Related: quasarframework/quasar-testing#403

Fixed by #20918