How to use css from node_modules?

[pschyska]

I'm trying to use @patternfly/react-core with snowpack, which includes css and assets that I need to include.

Just importing the css doesn't work

@import "@patternfly/react-core/dist/styles/base.css";

In dev, snowpack doesn't install any referenced assets, and I didn't find a way to make it. The css references some images and a lot of font files via url("./assets/.... The files are all present in node_modules/@patternfly/react-core/dist/styles/assets/, but are neither installed to .cache/snowpack/development:

node_modules/.cache/snowpack/development/@patternfly
node_modules/.cache/snowpack/development/@patternfly/react-core.js
node_modules/.cache/snowpack/development/@patternfly/react-icons.js
node_modules/.cache/snowpack/development/@patternfly/react-core
node_modules/.cache/snowpack/development/@patternfly/react-core/dist
node_modules/.cache/snowpack/development/@patternfly/react-core/dist/styles
node_modules/.cache/snowpack/development/@patternfly/react-core/dist/styles/base.css

... and in build none of the files end up in build/.

I think this use case is common enough that it should "just work" and it's a bug that the install step doesn't install dist/styles/assets/ etc. pp. Just copying the package to .cache/build/web_modules as-is would do it probably, and the bundler downstream (optimize/esbuild for now in my case) would do the right thing with the assets (rebasing, inlining or whatever). The way it is now the bundler has no chance to resolve ./assets, because the imported file has already been rebased to build/web_modules/@patternfly/react-core/dist/styles/base.css without pulling through the referenced resources.

I went through multiple iterations of trying to get it to work somehow but didn't find a way.
When I mount /assets like this:

  "./node_modules/@patternfly/react-core/dist/styles/assets": {
    url: "/assets",
  },

It seems to work in dev, but break for build. /assets is not copied into /build, and then the esbuild step fails because the .css still references ./assets which would be somewhere in /build. I think this is another bug, if a mounted directory is specified, the contents should surely end up in build/ somewhere? I can't imagine a use-case where you wouldn't want that.

I tried to use import aliases, but these don't seem to take effect for url(). I tried to do things myself with postcss, but didn't get it to work either.
Even importing the file directly in src/index.css as ../node_modules/@patternfly/react-core/dist/styles/base.css doesn't work!
Snowpack tries to find it in two nonsensical locations:

[snowpack] [404] /node_modules/@patternfly/react-core/dist/styles/base.css
  ✘ /home/p/projects/effective-javascript/public/node_modules/@patternfly/react-core/dist/styles/base.css

... but not in the path I gave it: /home/p/projects/effective-javascript/src/../node_modules/@patternfly/react-core/dist/styles/base.css

I tried to understand what webDependencies, install, or installOptions exactly do, but couldn't from the documentation.

Making a symlink in public/ to ../node_modules/@patternfly/react-core/dist/styles (the "brute-force" solution...) only works in dev, however when building esbuild throws hundreds of errors like this:

styles/base.css: error: File could not be loaded: styles/assets/fonts/overpass-webfont/overpass-heavy.eot
    440 │   src: url("./assets/fonts/overpass-webfont/overpass-heavy.eot");

While the file does in fact exist, in public/styles/assets/..., and also in build/:

± file build/styles/assets/fonts/overpass-webfont/overpass-heavy.eot
build/styles/assets/fonts/overpass-webfont/overpass-heavy.eot: Embedded OpenType (EOT), Overpass Heavy family

(Is this maybe related to the change in cwd behaviour of esbuild that popped up lately @FredKSchott ?)

So not even copying everything into public/ seems to work? What am I doing wrong?

[martinpitt]

I just stumbled over this as well. My current workaround is to do

import '@patternfly/patternfly/patternfly.css';

This is quite some overkill (especially if you try to webpack this for production), but it salvages at least the broken CSS. Fonts etc. are of course still broken.