Snowpack won't include referenced font files in CSS

[jquesada2016]

I noticed when trying to host material-icons from respective npm package, along with any other package that uses font files, Snowpack does not include these files referenced in CSS.

For example:

@font-face {
  font-family: "Material Icons";
  font-style: normal;
  font-weight: 400;
  src: url("MaterialIcons-Regular.eot");
  src: local("Material Icons"), local("MaterialIcons-Regular"), url("MaterialIcons-Regular.woff2") format("woff2"), url("MaterialIcons-Regular.woff") format("woff"), url("MaterialIcons-Regular.ttf") format("truetype");
}

From the code above, MaterialIcons-Regular.eot and MaterialIcons-Regular.ttf aren't included in either production build, or dev build. I saw a very similar issue referenced in #389. I set up postcss as mentioned, but had no success with it. Any help, advice, or guidance would be greatly appreciated!

[FredKSchott]

You're right! We have find support for importing individual CSS files (@import 'material-icons/some-file.css';) but aren't good at including the referenced assets. You're going to either want to vendor these yourself (add them to public/fonts manually) or add add each file individually to your install array in your snowpack.config.js file.

Someone shared an npm package a while back that let you scan the imports of a CSS file. I think the enhancement here would be to scan every imported CSS file for imports & url references, and then include them in the website build.

[delaneyj]

Can confirm that copying the files works ( atleast in the case of fontface fonts). However that definiately isn't a great long term way to do thing. Not sure how to use the install section of the snowpack.config.js. In the fontface example it needs its woff|2 files at files/fontname-*.woff. Would it be better to alias or something so that node_modules/fontface-inter for example was an additional public path?

[bmaranville]

I am having this issue as well... I have added font files to the "install" array but they don't seem to be included in the build at all.

[rikoe]

What also seems to work for us, although it is a bit hacky, is mounting the files directly from node_modules, e.g.:

  mount: {
    public: {url: '/', static: true},
    src: {url: '/dist'},
    'node_modules/@fontsource/roboto/files': '/files',
  },

This is just for dev mode though, they still need to be packaged during build.

Is there a way to do something similar during build?

[Xeevis]

Works great, even for production build.

  mount: {
    "../../node_modules/@fontsource/poppins/files": {
      url: "/css/files",
      static: true,
    },
    "../../node_modules/bootstrap-icons/font/fonts": {
      url: "/css/fonts",
      static: true,
    },
  },

Only downside is that it needs the extra config declaration and that it copies all files in those folders even if you don't necessarily need all.

[Laegel]

@FredKSchott Talked about using install property which—if I understand well—has been deprecated for packageOptions.knownEntrypoints (referring to https://www.snowpack.dev/reference/configuration#install).

Problem is that packageOptions.knownEntrypoints doesn't seem to have any effect in my case (https://github.com/Laegel/contributio/blob/dev/assets/snowpack.config.js#L38).
Unless I forgot something?

[rikoe]

@FredKSchott how do we get this turned into a prioritized issue to get it added? This is a pretty crucial missing feature. I am willing to do a PR myself if someone can point me in the right direction...

Can you share the name of the package you mentioned that allows scanning the imports of a CSS file?

[ljani]

I guess this is the plugin in question (snowpack-plugin-relative-css-urls) and it's using replace-css-url.

[sebastienbarre]

That "snowpack-plugin-relative-css-urls" plugin looks promising, but I can't figure out why it's not working for me. Is it working for anybody else?

With snowpack 3, in build mode I'm still getting:

_snowpack/pkg/@fontsource/inter.css: error: Could not resolve "./files/inter-cyrillic-ext-400-normal.woff2"
    7 │   src: url('./files/inter-cyrillic-ext-400-normal.woff2') format('woff2'), url('./files/inter-all-400-normal.woff') format('woff');

I'm using https://github.com/fontsource/fontsource, aka "Self-host Open Source fonts in neatly bundled NPM packages."
Then in my index.jsx: import '@fontsource/inter/index.css';, which points to an index.css file containing basically a series of directives like these:

@font-face {
  font-family: 'Inter';
  font-style: normal;
  font-display: swap;
  font-weight: 400;
  src: url('./files/inter-cyrillic-ext-400-normal.woff2') format('woff2'), url('./files/inter-all-400-normal.woff') format('woff');
  unicode-range: U+0460-052F, U+1C80-1C88, U+20B4, U+2DE0-2DFF, U+A640-A69F, U+FE2E-FE2F;
}

I had hoped the plugin would resolve these relative paths, but they are still relative in build/_snowpack/pkg/@fontsource/inter.css
UPDATE: it seems the plugin ignores CSS files in node module packages...

[ljani]

Yes, node_modules is ignored, I was a little surprised too. Thus, I'm interested in a proper fix for this issue.

I use snowpack-plugin-relative-css-urls mainly with my own paid fonts. However, as a workaround for fonts in node_modules, you can get them working by vendoring the dependency either by copy-pasting or symlinking.

[sebastienbarre]

@ljani I see. So did you put them in public/fonts, adjusted the paths in there, and just referenced the css file from public/index.html? I guess the drawback is that I have to manually monitor updates to the font files from time to time...

Ideally it would be great if the default, Snowpack 3 starter example would support importing fonts from node package, this seems like a relatively common use-cases, but I might be completely wrong here.

[ljani]

I symlinked the package's directory containing the .css and .woff2 under src and imported them from my index.tsx. I guess .html would work too, but it seems I'm still stuck with my webpack habits.

[rikoe]

We are using @fontsource/roboto, and that package contains many font files of various weights and styles.

Below is just a subset.

When using this package, you can import just the font files you need by importing the relevant css file, like so:

import '@fontsource/roboto/300.css'

The css file includes multiple @fontface definitions which then imports only the relevant files for each type face, as can be seen below.

Adding or symlinking these files manually, and keeping it in sync with the definitions in the @fontface sections of each css file, would be a nigh impossible task.

What is needed is a solution where references like url('./files/roboto-all-300-normal.woff') is automatically resolved correctly from the relevant package in node_modules. This is standard practice in most bundlers.

For now, we are using the fonts from CDN in index.html to get around this issue, but that is not ideal for various reasons.

@font-face {
  font-family: 'Roboto';
  font-style: normal;
  font-display: swap;
  font-weight: 300;
  src: url('./files/roboto-cyrillic-ext-300-normal.woff2') format('woff2'), url('./files/roboto-all-300-normal.woff') format('woff');
  unicode-range: U+0460-052F, U+1C80-1C88, U+20B4, U+2DE0-2DFF, U+A640-A69F, U+FE2E-FE2F;
}
/* roboto-cyrillic-300-normal*/
@font-face {
  font-family: 'Roboto';
  font-style: normal;
  font-display: swap;
  font-weight: 300;
  src: url('./files/roboto-cyrillic-300-normal.woff2') format('woff2'), url('./files/roboto-all-300-normal.woff') format('woff');
  unicode-range: U+0400-045F, U+0490-0491, U+04B0-04B1, U+2116;

[rossjrw]

Noting that the above comment describes the situation we're currently facing. We do not want to include these font files in our package directly, as that would defeat the point of the fontsource package.

[develar]

Same issue for element-plus UI framework. src:url(fonts/element-icons.woff) format("woff"),url(fonts/element-icons.ttf) format("truetype") is not supported by snowpack.

[FredKSchott]

Sorry that you all are running into this issue! You're right, npm packages are built into JS and while we have support for CSS inside of those packages, it looks like url references aren't being followed.

esinstall (our package bundler) should really support this, if anyone has some links for the best way to support font files in Rollup that would be great. Otherwise, your best bet is moving the package into a public source directory and serving the css/fonts out of there.

[xelius]

Hi, just ran into this issue when trying to use fontsource packages.

First - sorry if I'm mixing things up. I haven't looked into details and don't exactly feel totally on top of all the layers of integration going on here, but...

Snowpack uses esbuild under the hood and esbuild seems capable of handling url() references according to this: https://esbuild.github.io/content-types/#css.

It's not out of the box though, you need to tell esbuild what loader to use for the files, eg the file loader:

esbuild app.js --bundle --loader:.png=file --outdir=out

So my questions - 1) would this be a path to solving this issue and 2) is there a way in snowpack to pass options to change esbuild behaviuor like that?

[jugglingcats]

I am using webpack plugin to bundle so an esbuild specific solution wouldn't work in my case... just for info.

[xelius]

I see. But is esbuild complete out of the picture even when doing production bundling? My mental model is production plugins gets fed the output of the individually esbuild-built files...

Again, I could have this backwards.

[jugglingcats]

I think by default production build will use esbuild but you can tell snowpack to use webpack plugin. I can't remember why esbuild was not suitable for my app but I went with webpack

[jugglingcats]

Not sure xelius... I am not sure why you'd involve two bundlers but you might be right. @FredKSchott any comment?

[rossjrw]

This is an abomination but I've been able to get Fontsource imports working (#1573 (reply in thread)) using @snowpack/plugin-run-script.

The goal is to create a directory structure inside build/ that matches where Snowpack thinks the imported files should be, and then copy them there. For Fontsource's woff and woff2 files, that directory structure is files/. This solution may be applicable to other CSS imports, but I've not tried that.

In snowpack.config.js, construct a series of commands using @snowpack/plugin-run-script to create a build/files directory and copy all the font files you want there:

// Path to where Snowpack thinks the files should be found
const dirPath = "files"
// Template path to where the required files are actually found
const fontPath = "node_modules/@fontsource/roboto/files/roboto-all-$weight-normal.$ext"

module.exports = {
  plugins: [
    [
      "@snowpack/plugin-run-script",
      {
        name: "Copy Fontsource fonts (snowpackjs/snowpack#1573)",
        cmd: [
          `mkdir -p build/${dirPath}`,
          ...[
            fontPath.replace("$weight", "400").replace("$ext", "woff"),
            fontPath.replace("$weight", "400").replace("$ext", "woff2"),
            fontPath.replace("$weight", "700").replace("$ext", "woff"),
            fontPath.replace("$weight", "700").replace("$ext", "woff2")
          ].map(filePath => `cp ${filePath} build/${dirPath}`)
        ].join(" && ")
      }
    ],
    // other plugins
  ],
  // other config
}

You will obviously need to construct another cp command for each individual file you need to copy. Noting that the above example constructs Unix commands, so Windows users will need something different.

After doing this you don't need to change your CSS imports - import "@fontsource/roboto/latin-400.css" will still work provided that you've configured the build process to copy all of its required files.

I am pretty sure the files need to be copied into build/ even if you're not building your Snowpack output there. I have my buildOptions.out set to "dist" and the above solution verbatim works fine for both snowpack dev and snowpack build.

Provided that build/ is in your .gitignore, this method avoids you having to unnecessarily commit stuff that should be in an external package. The only thing that needs to change is your Snowpack config. Of all the solutions posed in this thread, this one feels the cleanest to me - it's a Snowpack problem, so the ugliness is confined to the Snowpack config.

EDIT: This doesn't work on CI - no idea why. I'm going back to Webpack

[jugglingcats]

This is also an abomination (perhaps worse!) but the above solution was sub-optimal for me as I have sub-directories to copy over, so I wanted something to scan and automatically copy everything given a sub-directory of a package. I also found that with semantic-ui-react, snowpack puts the build files in _snowpack/pkg, so the target path needs to be changed for some node_modules packages.

I created a "local" snowpack plugin in my project, using file path in package.json. This plugin implements the optimize lifecycle hook and doesn't seem to interfere with the webpack plugin, and runs before webpack if it appears before in the plugins list.

package.json

    "devDependencies": {
        "snowpack-plugin-copy": "file:plugins/snowpack-plugin-copy",
        ...
    }

snowpack.config.js

    plugins: [
        ["snowpack-plugin-copy", { modules: ["dseg/fonts", "!semantic-ui-css/themes"] }],
        ...
    }

plugins/snowpack-plugin-copy/index.js

const path = require("path")
const fs = require("fs")

function copy_file(src, dest, base_dir) {
    const relative_path = src.substr(base_dir.length)
    const target_file = `${dest}${relative_path}`
    const target_dir = path.dirname(target_file)
    // console.log("Copy file", src, target_file)
    fs.mkdirSync(target_dir, { recursive: true })
    fs.copyFileSync(src, target_file)
}

function copy_recursively(src, dest, base_dir) {
    const files = fs.readdirSync(src)
    for (const f of files) {
        const full_path = `${src}/${f}`
        const s = fs.statSync(full_path)
        if (s.isDirectory()) {
            copy_recursively(full_path, dest, base_dir)
        } else {
            copy_file(full_path, dest, base_dir)
        }
    }
}

function copy(...paths) {
    for (const module_path of paths) {
        if (module_path.startsWith("!")) {
            const pkg = module_path.substr(1)
            const source_dir = `node_modules/${pkg}`
            const target_dir = `build/_snowpack/pkg/${pkg}`
            copy_recursively(source_dir, target_dir, source_dir)
        } else {
            const dir = path.basename(module_path)
            const source_dir = `node_modules/${module_path}`
            const target_dir = `build/${dir}`
            copy_recursively(source_dir, target_dir, source_dir)
        }
    }
}

module.exports = function (snowpackConfig, pluginOptions) {
    const modules = pluginOptions.modules
    return {
        name: "snowpack-plugin-copy",
        optimize() {
            copy(...modules)
        }
    }
}

The ! in the module path indicates it should be copied to build/_snowpack/pkg.

I have no doubt that this will fail badly in some future version of snowpack, but it seems to do the trick for now.

My question on best practice is here... #2781. There has to be a better way?

[eytienne]

@jugglingcats I learnt the "file:" thing but maybe it will be simpler with a relative path to your plugin.js

[wmhartl]

+1 on prioritizing getting this working

[melissamcewen]

Hi @wmhartl would you be willing to file a feature request on this? Or a bug if you think it should work https://github.com/snowpackjs/snowpack/issues/new/choose

[fredDesign]

Any news on the priority for this bug/feature

[fredDesign]

nothing new on this point for make our code more accurate .. Silence ... same for the problem on sourcemaps ...
more and more I think to moove on other techno (vite maybe)

[schotime]

I just tried to convert to vite and ran into a heap of esbuild errors. I think its worse than css ones. Already had to change 20 files and its still not running.