Trouble loading fonts from Semantic UI #826
Comments
|
This happens because the file does not have the |
|
@evanw Many thanks for the fast response and fix. I've confirmed that the fix works. I also love the way you solved it. I haven't quite gotten my build working yet, but feeling really good about esbuild. :) Is there a succinct way to configure a loader for multiple file types? If I understand correctly, I think I need to use the npx esbuild lib/index.jsx --bundle --sourcemap \
--outdir=build \
--define:process.env.NODE_ENV=\"production\" \
--loader:.png=dataurl \
--loader:.woff=dataurl \
--loader:.woff2=dataurl \
--loader:.eot=dataurl \
--loader:.ttf=dataurl \
--loader:.svg=dataurl |
No, there isn't really. Each file type is explicit. You could write a plugin I suppose but the plugin code would be bigger than just using the loader commands.
The CLI is only really intended for simple uses of esbuild. More complex uses should probably use the API instead: require('esbuild').build({
entryPoints: ['lib/index.jsx'],
bundle: true,
sourcemap: true,
outdir: 'build',
define: {
'process.env.NODE_ENV': '"production"',
},
loader: {
'.png': 'dataurl',
'.woff': 'dataurl',
'.woff2': 'dataurl',
'.eot': 'dataurl',
'.ttf': 'dataurl',
'.svg': 'dataurl',
},
})This is about equivalent verbosity of course, but having it in a separate file and being able to use real programming language syntax makes it less unwieldy IMO. You could also then use code to construct the |
|
For me, the main selling point of esbuild is the simple DX and good defaults (as opposed to performance). I haven't needed any plugins yet and for the most part everything "just works". The CLI is an important part of the simple DX because it makes it easy to switch between modes (e.g. turn I wonder if you would be willing to support a config file so that we could put some options in a file but still use the CLI? Rollup supports this via the For example, my Rollup config file looks like this: import babel from '@rollup/plugin-babel';
import commonjs from '@rollup/plugin-commonjs';
import resolve from '@rollup/plugin-node-resolve';
import replace from '@rollup/plugin-replace';
import { terser } from 'rollup-plugin-terser';
import postcss from 'rollup-plugin-postcss';
import json from '@rollup/plugin-json';
// `npm run build` -> `isDev` is false
// `npm run dev` -> `isDev` is true
const isDev = Boolean(process.env.ROLLUP_WATCH);
export default {
input : 'lib/index.jsx',
output : {
file : 'build/app.js',
format : 'esm',
sourcemap : true
},
plugins : [
resolve({
extensions : ['.js', '.json', '.jsx'],
browser : true
}),
commonjs({ include : 'node_modules/**' }),
postcss({
modules : {
globalModulePaths : [
/node_modules\/react-credit-cards\/es\/styles-compiled.css/u,
/node_modules\/react-image-crop\/dist\/ReactCrop.css/u,
/node_modules\/semantic-ui-css\/components\/.*\.css/u
]
}
}),
// This is needed to fix React assuming the browser has `process`
replace({ 'process.env.NODE_ENV' : JSON.stringify(isDev ? 'development' : 'production') }),
json({ preferConst : true }),
babel({
babelHelpers : 'bundled',
exclude : 'node_modules/**'
}),
!isDev && terser()
]
};The beauty of this is that it is dynamic like the API but it preserves the convenience of the CLI. It also simplifies npm scripts, mine are just: "scripts": {
"build": "rollup --config",
"dev": "rollup --config --watch"
},If it weren't for the lack of a default loader for some of those file types, I wouldn't even feel the need for a config file, I'd probably just keep everything in npm scripts, which would be even more awesome. |
No, I am not willing to do this. I think the API is a better design than a config file. Using the API is about the same amount of code as using a config file but it's much more flexible because it doesn't take away your abstraction capabilities. I went into this in more detail in #536 if you're interested.
The nice thing about the API vs. a config file is you are in control, not esbuild. Doing something like that is trivial with |
|
Alright, well thank you for considering. I'll make a wrapper CLI and publish it to npm in case others find it useful. FWIW, I don't see these things as mutually exclusive. An API is great for complex use cases, but it's never going to compete with a CLI in terms of ergonomics, which I'm sure is why esbuild has a CLI to begin with. |
|
@evanw what's about the package resolution syntax in css like this And thank you so much for esbuild and great work! |
|
@izatop , you ever figure that one out? Just started an Angular 16 upgrade with experimental ESBuild support, and it's failing on font files from fortawesome. |
|
@AStoker I solve that case by plugin which resolves paths starting at |
|
Hmmm, yeah, I don't think that's the case that's going on with me (the tilde is actually deprecated with latest sass). I'll keep digging, but thanks for the reply! |
I use Semantic UI React as my component library. It's generally combined with
semantic-ui-cssto provide CSS styles. Unfortunately, something about the@font-facerules insemantic-ui-csstrips up esbuild.With an
index.jsxentry point file of simply:... I get errors when I run esbuild, such as:
I'm not sure what the best approach is for dealing with these assets, but the paths are correct and the files do exist on disk. It works with my current Rollup setup. Do I need to specify some kind of loader? It would be nice if esbuild could give a more actinable error message.
esbuild v0.8.46
Node v15.7.0
semantic-ui-css v2.4.1
The text was updated successfully, but these errors were encountered: