Having two different webpack rules setup for the same file type but
assigned to different set of files (by means of include, exclude, issuer)
fails if files affected by one rule import files affected by the other rule.
This is particularly true for image files used in a style file and passed through
url-loader.
This repository demonstrates the issue and is an attachment to issue 178 at webpack url-loader repository.
To reproduce the issue, clone this repository to your local file.
Then run npm install.
After successful installation, run the following script to build the project and start the development web server:
npm run buildAndRun:DevThis will start webpack-dev-server at http://localhost:8080/.
Open http://localhost:8080/test.html to see the effect.
This sample project contains three components, establishing an import chain:
-
The
test.htmlweb page imports theouter-wcweb component. -
The
outer-wcweb component itself imports theinner-wcweb component.
The inner web component utilizes url-loader for importing its images, stored in a
SCSS file:
{
test: /\.(png)|(svg)|(je?pg)|(gif)$/i,
use: 'url-loader',
issuer: {
include: /src[/\\]inner[/\\].*\.(ts)|(scss)$/
}
}inner-wc > div
{
background: white url("../img/Throbber.gif") center no-repeat;
}The outer web component, however, utilizes file-loader for importing its images,
stored in a SCSS file:
{
test: /\.(png)|(svg)|(je?pg)|(gif)$/i,
use: {
loader: 'file-loader',
options: {
outputPath: 'images',
name: "[name].[ext]"
}
},
issuer: {
include: /src[/\\]outer[/\\].*\.(ts)|(scss)$/
}
}outer-wc > div.outer
{
background: white url("../img/Throbber.gif") center no-repeat;
}(Note: This is a sample repository, boiled down to demonstrate the issue.)
-
The
data:URL generated byurl-loaderfor the styles oninner-wcisn't the BASE64 encoded binary image data. Instead, it's the BASE64 encoded JavaScript string:'module.exports = __webpack_public_path__ + \"images/Throbber.gif\";' -
While
file-loadercopies the image file to thedistfolder, the styles generated by it don't refer to the copied image file, instead, adata:URL is falsely generated. Moreover - again - thedata:URL doesn't contain a BASE64 encoded binary image data. Instead, it's the above BASE64 encoded JavaScript string.
In this setup ...
-
url-loadershould create a valid BASE64 encoded image URL forinner-wc, but not forouter-wc. -
file-loadershould not only copy the image file but also set the correct relative URL in the style sheet forouter-wc. -
inner-wc's imports should not be touched byfile-loaderas the rule forouter-wcdoes not apply toinner-wc. And vice-versa.


