Option to ignore not found modules/URLs

[Aleksanderis]

Do you want to request a feature or report a bug?
It would be good to have an option to skip not found URLs instead of throwing "Module not found" errors.
It might be just a warning instead of critical error, or just skipped.
Ignoring all URLs and @imports, which is already supported - is not an option, since it's too global.

What is the current behavior?
When URL is not found it throws the error in following format:

ERROR in ./~/css-loader!./src/css/site.css
Module not found: Error: Can't resolve '../../node_modules/somelibrary/not-existing.gif'

This error eventually fails the whole webpack build.

What is the expected behavior?
If some options is enabled, such error becomes not critical and build is not marked as failed.

If this is a feature request, what is motivation or use case for changing the behavior?
Motivation is that when you rely on third-party library you cannot be sure they will include all files referenced in their vendor.css. We are forced (corporate branding stuff) to rely on some internal (but still third-party library - i.e. different team responsibility), which works following some strange bureaucracy workflow and bad publishing practices. So not including all referenced files - is a common case..

Please mention other relevant information such as your webpack version, Node.js version and Operating System.
Would it be possible to implement such feature or are there any blockers why it wasn't made already so?
Or maybe there are other ways to achieve same thing?

[michael-ciniawsky]

@Aleksanderis It's depending on general usage, if it is possible to just display warnings and the build succees and works this would be a good idea. On the oher hand we already have a ton of url and @import releated issues because of the ambiguity of the resolver and trying to make it saner in the upcoming v1.0.0 release. I'm not against this feature by any means but the architecture and possible edge cases, where this might even break other code must be well thought of beforehand. If you have something in mind please send a PR for discussion (doesn't need to be perfect)

[Aleksanderis]

@michael-ciniawsky , sorry I'm quite new to webpack itself, and completely know-nothing yet in terms how webpack plugins/loaders are written inside. I didn't want to blame anyone, just was curious how easy it could be or couldn't be at all implemented.;)

But.. are you saying that it's actually not css-loader issue, but common way how webpack loaders work (or how third-party libraries, common for webpack loaders, are working)?
You mentioned something about resolver, and I reviewed Module not found error stack trace and found out that error comes from enhanced-resolve\lib\Resolver.js (which is not part of css-loader). Is it same resolver you were referencing?

Do I understand correctly how it works: css-loader just parses "url", "@import" and stuff like that, and just collects all potential "modules". After it - it's given to resolver (or webpack itself) to resolve these modules, and css-loader basically doesn't have control over it. So to implement what I'm asking, css-loader would need to try resolving everything additionally (which is of course potential performance drawbacks, and possible other issues). Did I get it correctly, or is it a little bit more complicated? ;)

[michael-ciniawsky]

But.. are you saying that it's actually not css-loader issue

@Aleksanderis Yes and no 😛

entry.js

import lib from 'lib' // Parser => Resolver => Tapable(Core Plugins, Plugins)
import css from './style.css' // Parser => Resolver => Tapable(Core Plugins(e.g Loader(s)), Plugins)
import component from './component' // Parser => Resolver => Tapable(Core Plugins, Plugins)

...

loader.js

module.exports = function (source, map) {
   console.log(this) // ~.context, ~.resource, ~.resourcePath ~.resolve => Resolver + others

   ...transform(source, map)

   return this.async(Error, source, map)
}

You mentioned something about resolver, and I reviewed Module not found error stack trace and found out that error comes from enhanced-resolve\lib\Resolver.js

Yep right this is the webpack Resolver I was referring to. It will provide metadata for webpack Loaders after resolving the module (see above)

Do I understand correctly how it works: css-loader just parses "url", "@import" and stuff like that, and just collects all potential "modules". After it - it's given to resolver (or webpack itself) to resolve these modules, and css-loader basically doesn't have control over it. So to implement what I'm asking, css-loader would need to try resolving everything additionally (which is of course potential performance drawbacks, and possible other issues). Did I get it correctly, or is it a little bit more complicated? ;)

The webpack Resolver and mainly a Core Plugin called Module Factory, first resolves the path in the parsed import/require statements and depending on the file extensions ({ test: /\.extname$/ }) try to call the appropiate loader (via loader-runner) for it when file.extname !== .js && module.rules.use[index].test

webpack.config.js

{
   module: { // => Settings for Parser, Resolver, Module Factory
     rules: [ 
          {
             test: /\.css$/,
             use: { loader: 'css-loader' } 
          }
     ]
}

css-loader has control over the transform and what is provided via this (Loader API), but it is basically a function called when the rule it was set on matches 😛 . There should be a this.outputPath on the API aswell, but with the ocean of usecases your feature request may or may not break some of them or have other side effects, it is complicated when it comes to that, since many maybe(s) need to be evaluated beforehand. But that doesn't mean it isn't possible or taken into regard so any proposal / demo repo / futher investigation you can provide are highly welcome and we will see what is possible :). Also note that my explanations are only a Loaders Author 101 at best and maybe not 💯 appropiated when it comes to webpack Core architecture in detail :D

[Astridax]

I'm also facing this issue. Currently what I'm planning to do is resolve it by making a dummy image and using the alias function to resolve to the dummy image.

Maybe this could either be a feature where it simply warns about unresolved files, or even where you can specify the URLs to ignore as per the alias syntax?

[petermikitsh]

Motivation is that when you rely on third-party library you cannot be sure they will include all files referenced in their vendor.css. We are forced (corporate branding stuff) to rely on some internal (but still third-party library - i.e. different team responsibility), which works following some strange bureaucracy workflow and bad publishing practices. So not including all referenced files - is a common case..

I don't think I could state it better. This feature would be great -- I have the exact same use case. I would prefer if Webpack handled the situation gracefully. Instead of exploding, just don't resolve the imports, and create a CSS file I can use. In this particular case, the fact that modules don't resolve does not matter.

[petermikitsh]

To anyone who might still be looking for a workaround, instead of processing these 'bad' CSS files (ones that have url()'s referencing missing files, etc), I'm using the raw-loader like so:

const Styles = require('!raw-loader!mystyles.css');

// later in my React component implementation

<style dangerouslySetInnerHTML={{__html: Styles}} />

It doesn't achieve the same goal as this issue (e.g., if you're extracting your CSS, this CSS will end up instead in your JS bundle), but it gets the job done.

[stereokai]

Would love a solution for this.

[tomasdev]

Alternatively, what would be a resolver-for-not-founds-loader look like? all I found in docs, is mapping requests filenames to different filenames, not to sources themselves (meaning one could do module.exports = '';)

[michael-ciniawsky]

#655

[Grohden]

@michael-ciniawsky when the fix will be released?