🐛 BUG: css url() replaced by __VITE_ASSET__*

[hmvp]

What version of astro are you using?

0.21.11

What package manager are you using?

npm

What operating system are you using?

Linux on WSL2 (Ubuntu 20.04.3 LTS)

Describe the Bug

When adding a font from a npm package the font file url in the build is replaced by __VITE_ASSET__2adefcbc__

See the linked example. When adding a @font-face definition in global.css the result in the build is mangled. For the example I could not get the font to actually show on the astro dev page. But in my project (which I cannot share) everything works with astro dev but building does not. (In the example the actual font file is not copied to the build dir. This does happen in my project)

Link to Minimal Reproducible Example

https://stackblitz.com/edit/github-eehb2a-fggvjv?devtoolsheight=33&file=dist/assets/index.4daba237.css

[tusamni]

Just experienced this as well. Build doesn't include the font file, dev works fine.

[jonathantneal]

Confirmed. It works fine in dev, but the build is incorrect.

@font-face{
  font-family: "FA";
  font-style:normal;
  font-weight:300;
  font-display:swap;
  src: url(__VITE_ASSET__2adefcbc__) format("woff2");
}

[u0fexe]

Aliases and public paths also doesn't resolve

[jnmsl]

Same for me. I imported font from fontsource. Build folder contains imported font files but the names of them are replaced by VITE_ASSET__hash inside of css. The hash is right but the name of the asset is missing in the css.

Code

import '@fontsource/inter/index.css';
import '@fontsource/inter/400.css';

Result

Build folder:
inter-latin-400-normal.2069ee22.woff2

CSS:
src: url(__VITE_ASSET__2069ee22__) format("woff2");

[jnmsl]

Similar issue in vite repo: vitejs/vite#1602

[retronav]

This issue is still present for me. Using Astro v0.22.9.
@jnmsl Looks like the intent of that issue was clearly misunderstood when making this commit that closed that issue: vitejs/vite@e6c8478

[hans-d]

As I understand vite is vendored within Astro, so the fix is most likely not yet in the version Astro is using.

just checked, the fix is present

[retronav]

Till the original issue gets solved, I have created a post-build script to replace the __VITE__ASSET__s : https://gist.github.com/retronav/9fe57bf44fdcbd9efa6e3eb3aab91943
You may run this script after completing the build.

EDIT: updated the script URL

[retronav]

From further findings, this issue should have been be fixed by vitejs/vite#5729

[mtakemoto]

This looks like a duplicate of #2453. Hoping the upstream PR that @matthewp made in Vite will fix this too.

Also thanks for that script @obnoxiousnerd I can confirm that it worked perfectly.

[Abhi13027]

Any update on this issue

[marianheinsen]

I'm also having this issue. Would be great to get an update if this is being fixed

[retronav]

@Abhi13027 @marianheinsen Looks like the upstream issue in Vite (vitejs/vite#6625) is still open so I think we're waiting for a response. In the meantime feel free to use the workaround I posted above in this thread 🙂.

[schlichtanders]

Till the original issue gets solved, I have created a post-build script to replace the __VITE__ASSET__s : https://gist.github.com/retronav/9fe57bf44fdcbd9efa6e3eb3aab91943 You may run this script after completing the build.

EDIT: updated the script URL

How to run the script after normal build?

[marianheinsen]

@schlichtanders You can run the script by executing the command node fixViteAssets.mjs in the terminal.
You can also change your build command in the package.json file from
"build": "astro build",
to
"build": "astro build && node fixViteAssets.mjs",
to automatically run this command after every Astro build

[matthewp]

I'm looking into this one now again.

[matthewp]

Update here:

I was able to get this problem to be fixed in this branch: https://github.com/withastro/astro/tree/fix-vite-asset

However, to fix it we need to essentially hand-over CSS bundling to the Vite CSS plugin. One constraint of Astro is that we want each page to generate its own CSS file (not be bundled all together).

To do that we need to turn pages into dynamic imports, which the Vite CSS plugin will then split. However, this also means that each page becomes its own chunk in the SSR build. We wanted to have a single JS file for SSR because we were under the impression that some hosts, like Cloudflare, required that. We need to confirm if this is the case.

If that is the case it's back to the drawing board. If not and dynamic imports are ok we can go with the approach prototyped in that branch.

cc @FredKSchott

[FredKSchott]

Ah dang, that's annoying. I'd really like to avoid the dynamic import() of each page, and keep the simplicity of the single-file SSR output.

From quickly reading the Vite docs, it sounds like we'll need to somehow define these chunks ourselves. https://vitejs.dev/guide/build.html#chunking-strategy. Asking the Vite team for guidance on this may also be a good idea.

@matthewp this is probably worth punting on until next cycle, where we could dedicate some dedicated time to solving this PLUS tackling/auditing/finalizing the overall Astro output performance story, all together.

[matthewp]

The latest comment above is still relevant here. To summarize:

1. Allow vite-css to do CSS bundling, in which case we need to turn our page imports into dynamic imports. This might have implications for SSR single-bundle rule.

• Rollup does have a way to inline dynamic imports, maybe we can use that?

2. Take over CSS entirely, probably not a good idea.

[FredKSchott]

Related notes:

• there's a rollup option inlineDynamicImports that we should look into, especially since dynamic import()s inside of Astro components may be breaking our "1 file output guarantee" anyway.
• This is another option that would give us control: https://rollupjs.org/guide/en/#outputmanualchunks
• Vite team could give guidance

[matthewp]

This bug is finally fixed and has went out with astro@1.0.0-beta.35.

[andrioid]

Are we sure this is fixed? If I import "@fontsource/montserrat" in my index.astro on beta.40 project, the builds fail.

• npm run dev works fine
• npm run build fails with: Cannot find module '/workspace/astro/examples/minimal/dist/chunks/chunk.a04a3cfa.mjs' imported from /workspace/astro/examples/minimal/dist/entry.mjs

This can be reproduced in the minimal example in the Astro repo (beta 40) by adding the font and trying to import it, or just use my Gitpod

[simonwiles]

@andrioid same here; tried using @fontsource because I couldn't find any way to successfully reference self-hosted fonts inside my src/ folder, but hit exactly the same issue you're having...

[FredKSchott]

Bah! Was really looking forward to this one. Pinging @matthewp to take a look at this (fontsource would be a good package to get a specific test for, since it will most likely be our recommended "good perf google fonts" workflow)

[andrioid]

As a work-around, it’s possible to do a @import '@fontsource/whatever' in yout CSS file instead. That works for both dev/build.

Thanks to Fred, for mentioning it on Discord.

[matthewp]

Can you create a stackblitz? I can't access your gitpod. Are you importing within CSS or in the frontmatter? This issue is about importing within css (in a style tag should work).

[andrioid]

Can you create a stackblitz? I can't access your gitpod. Are you importing within CSS or in the frontmatter? This issue is about importing within css (in a style tag should work).

Sorry, I missed that this was from within CSS. The symptoms matched. I'm importing the font inside index.astro. I can create a new issue, if this is way off topic.

Here's a Stack "Blitz": https://stackblitz.com/github/wmailambn?file=src/pages/index.astro

• Runs in dev
• Fails in build

[matthewp]

@andrioid I still can't access that, strangely. You sure you don't have that marked as private?

This specific issue is where some __VITE_ASSET__ strings gets left in your bundled CSS. If you are getting an error build it is likely a different issue. Can wait and see what the issue is first.

[andrioid]

No __VITE_ASSET__ here, so I guess you can close this one. I'll write up a new issue and provide as much info as I can.

[matthewp]

@andrioid That stackblitz probably works, I just can't access it for some reason :(

[matthewp]

Was able to recreated, it's not a __VITE_ASSET__ thing but still an important bug. #3536