Webpacker: componentWillAppearSVG Images shared in scss and in js cause webpack dev server error

[raldred]

//edit This issue seem only to happen when SVGs are linked from JS and used a link css module.

If css modules are imported into the pack that share images linked in JS a very odd require error is thrown upon loading my pack from the WDS in the browser.

This seems to only happen when css is imported before images, switch it around and import the image into the pack before importing the css and it I think it seems to fix it.

application.scss:1 Uncaught TypeError: __webpack_require__(...) is not a function
    at Object.<anonymous> (application.scss:1)
    at __webpack_require__ (bootstrap 34c97717b1e32b9adcd6:19)
    at bootstrap 34c97717b1e32b9adcd6:62
    at application-dd01bfaa25026502c2f1.js:66

Offending line 1:

exports = module.exports = require("../../../node_modules/css-loader/lib/css-base.js")(true);
// imports

// module
exports.push([module.id 
// .....................

//exports

//////////////////
// WEBPACK FOOTER
// ./node_modules/css-loader?{"minimize":false,"sourceMap":true,"importLoaders":2}!./node_modules/postcss-loader/lib?{"sourceMap":true,"config":{"path":"/Users/robaldred/Code/marketing/.postcssrc.yml"}}!./node_modules/sass-loader/lib/loader.js?{"sourceMap":true}!./app/javascript/css/residents.scss
// module id = 2
// module chunks = 0

application.js

import 'styles/application'
import 'images/background'

application.css

body {
  background-image: url('../images/background.jpg');
}

Flipping the import order around so the image is imported first fixes the issue.

Webpacker: 3.2.2
Webpack: 3.11.0
WDS: 2.11.1

I'm using out the box config webpacker.
Have the following structure.

  javascript
    packs
      application.js
    styles
      application.scss
    images
      background.jpg

[GabLeRoux]

I am not getting this error with these versions:

Webpacker: 3.2.2
Webpack: 3.11.0
webpack-dev-server: 3.0.0

Maybe you should try to upgrade your webpack-dev-server. On my side, I'm using url-loader to load images:

config/webpack/environment.js:

const { environment } = require('@rails/webpacker')

// https://github.com/rails/webpacker/issues/1119#issuecomment-352388302
// resolve-url-loader must be used before sass-loader
environment.loaders.get('sass').use.splice(-1, 0, {
    loader: 'resolve-url-loader'
});

module.exports = environment

I installed resolve-url-loader like this:

yarn add resolve-url-loader -D

Seems to work fine with resolve-url-loader version 2.2.1

ps; I don't import my styles from application.js, I use <% stylesheet_pack_tag "application.css" %> directly within my erb files. Hope that helps.

[raldred]

Apologies, my report wasn't quite correct, I have since discovered that it's specifically related to using SVGs as background images used in css loaded via the import syntax.

.icon {
  background-image: url('../images/icon.svg');
}

I too am using stylesheet_pack_tag to included the css generated by webpack

[maschwenk]

I have the same issue, sounds like it won't be fixed with just upgrading Webpack, I've seen the resolve-url-loader fix mentioned in a lot of other places

[raldred]

i thought the resolve-url-loader was only required for assets not relative to the output location eg for legacy asset pipeline objects.

Will give it a whirl and report back.

[maschwenk]

@raldred I'm still having this issue, tried a bunch of different things to no avail. Any luck? It feels like this is maybe due to loaders not running in a deterministic order @gauravtiwari ?

[gauravtiwari]

@raldred Yes that's correct, you don't need resolve-url-loader unless need to resolve non-relative assets.

@maschwenk @raldred Are you using any loaders for processing files (like svg loader)? The file loader is pretty simple and returns file path so don't think it should cause any JS error.

What version of file loader are you using? Have you tried latest webpacker? (going to look into this now)

[maschwenk]

@gauravtiwari Awesome! this has been driving me nuts. I was using svg-loader initially, but I removed it because it was just making the issue more complex.

I have my images under assets/images and have set my resolved_paths to include that folder. I've tried removing resolve-url-loader completely and just using tilde references like ~/image_folder/abc.svg and that fixes this issue locally, but breaks when compiling in production mode. It looks like it breaks sourcemaps.

I'm using webpacker 3.0.2 (and therefore file loader 0.11.2)

To reduce the number of variables I'm going to first try to upgrade to the newest webpacker and move from there, but I think the result will be the same (but it'll be easier for you to debug @gauravtiwari )

It feels like you should be able to _only_ use file-loader and add to your resolved_paths and then there's no need for resolve-url-loader but that seems to not be the case

[gauravtiwari]

Just tried to reproduce it but couldn't. Please see an example repo here: https://github.com/gauravtiwari/webpacker-svg-example

Could you both take a look and see if I am missing something here?

[raldred]

I'll checkout the repo in the morning to check properly but at a glance you're not using the image with asset_pack_path

[raldred]

@maschwenk the only solution I have at the moment is to not use SVG images in the css imported into the pack, no such issues with JPG or PNG images.

@gauravtiwari out the box install of webpacker and config.

[gauravtiwari]

@raldred Thanks, could you please post more info in the morning?

asset_pack_path

??

[maschwenk]

@gauravtiwari he means throwing it at the bottom like this I think.

<h1>Pages#index</h1>
<p>Find me in app/views/pages/index.html.erb</p>
<%= stylesheet_pack_tag 'hello_react' %>
<%= javascript_pack_tag 'hello_react' %>
<%= asset_pack_path 'images/SVG_logo.svg' %>

With that repo and the asset_path_path I was unable to repro either. To be clear my current repro steps are.

1. start the server with webpacker-dev-server up
2. make a change to a sass file
3. blows up with errors described above

other case:

1. start the server with webpacker-dev-server up
2. make a change to a js file
3. doesn't blow up

It feels to me like this is some kind of non-deterministic behavior of the order of webpack loaders

[raldred]

FYI, this appears to have been fixed by bringing webpack up from 3.5 to 3.11