Loaders | webpack

Loaders are transformations that are applied to the source code of a module. They allow you to pre-process files as you import or “load” them. Thus, loaders are kind of like “tasks” in other build tools and provide a powerful way to handle front-end build steps. Loaders can transform files from a different language (like TypeScript) to JavaScript or load inline images as data URLs. Loaders even allow you to do things like import CSS files directly from your JavaScript modules!
For example, you can use loaders to compile Sass to CSS or to convert TypeScript to JavaScript. To do this, you would start by installing the loaders you need:
And then instruct webpack to use the sass-loader for every .scss file and the ts-loader for all .ts files:
Plain .css files need no loader at all: webpack's built-in CSS support, on by default, parses, extracts and minifies CSS itself — see experiments.css and the Native CSS guide. A preprocessor still needs its loader, and type: 'css/auto' hands what the loader produces to webpack's CSS pipeline.
There are two ways to use loaders in your application:
Note that loaders can be used from CLI under webpack v4, but the feature was deprecated in webpack v5.
module.rules allows you to specify several loaders within your webpack configuration. This is a concise way to display loaders, and helps to maintain clean code. It also offers you a full overview of each respective loader.
Loaders are evaluated/executed from right to left (or from bottom to top). In the example below execution starts with sass-loader and ends with postcss-loader. See "Loader Features" for more information about loaders order.
It's possible to specify loaders in an import statement, or any equivalent "importing" method. Separate loaders from the resource with !. Each part is resolved relative to the current directory.
The loader1!loader2!./file syntax is shown for illustration. In most projects, prefer configuring loaders via module.rules and importing styles for their side effects (e.g. import "./styles.css").
It's possible to override any loaders, preLoaders and postLoaders from the configuration by prefixing the inline import statement:
Prefixing with ! will disable all configured normal loaders
Prefixing with !! will disable all configured loaders (preLoaders, loaders, postLoaders)
Prefixing with -! will disable all configured preLoaders and loaders but not postLoaders
Options can be passed with a query parameter, e.g. ?key=value&foo=bar, or a JSON object, e.g. ?{"key":"value","foo":"bar"}.
Use module.rules whenever possible, as this will reduce boilerplate in your source code and allow you to debug or locate a loader faster if something goes south.
Loaders provide a way to customize the output through their preprocessing functions. Users now have more flexibility to include fine-grained logic such as compression, packaging, language translations and more.
Loaders follow the standard module resolution. In most cases it will be loaded from the module path (think npm install, node_modules).
A loader module is expected to export a function and be written in Node.js compatible JavaScript. They are most commonly managed with npm, but you can also have custom loaders as files within your application. By convention, loaders are usually named xxx-loader (e.g. json-loader). See "Writing a Loader" for more information.
Copyright OpenJS Foundation and webpack contributors. All rights reserved. The OpenJS Foundation has registered trademarks and uses trademarks. For a list of trademarks of the OpenJS Foundation, please see our Trademark Policy and Trademark List. Trademarks and logos not indicated on the list of OpenJS Foundation trademarks are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
The OpenJS Foundation | Terms of Use | Privacy Policy | Bylaws | Code of Conduct | Trademark Policy | Trademark List | Cookie Policy