Use Rule.oneOf to resolve correct loader

[Furizaa]

This PR uses the oneOf rule to resolve loaders in webpack.config.prod.js. This will use the first loader that matches in the list of loaders provided by oneOf and enables us to remove the big exclusion list of the file-loader. The file loader will only be used if the module falls through all other loaders.

https://webpack.js.org/configuration/module/#rule-oneof

For some reason though I had to still preserve the js(x) exclusion in the file loader. Otherwise the build would break. This happens with or without the eslint preloader. Will have to investigate further why exactly this happens and why these unknown js(x) modules fall through to the file-loader.

The resolve now looks something like this (pseudocode):

[
  { 'eslint-loader', enforce: 'pre', test: 'javascript' },
  {
    oneOf: [
      { 'url-loader': test: 'images' },
      { 'babel-loader', test: 'javascript' },
      { 'style-loader', test: 'style' },
      { 'file-loader' },
    ]
  }
]

[gaearon]

This is sooo sweet. Thank you.
Still pending some work?

[Furizaa]

Thank @sokra as he pointed me in the right direction :D Yeah now I see I missed the dev config. Will add that in a bit.

[gaearon]

For some reason though I had to still preserve the js(x) exclusion in the file loader. Otherwise the build would break. This happens with or without the eslint preloader. Will have to investigate further why exactly this happens and why these unknown js(x) modules fall through to the file-loader.

Did you figure this part out?

[Furizaa]

Did you figure this part out?

Not yet. I can try my luck tomorrow but there is a chance I will come to no conclusion. Debugging webpack is a pain and __webpack_require__(...) is not a function does not really help there.

But -- I added oneOf to the dev config. Should be good now if you don't point me to a spot I missed :)

[gaearon]

Let's hang on until you try to figure it out. If you can't, no sweat, just write here and we'll get somebody familiar with webpack internals to look at it. I'd like to understand better before merging. Thank you!

[Furizaa]

Ok, I found out what the problem is and have two possible fixes for you. The culprit is the css-loader runtime that gets injected as a .js file that would then be loaded by the file-loader if we don't exclude .js files explicitly ('cause the babel-loader only matches paths.appSrc).

As a proof-of-concept I tried to patch the css-loader so that the runtime gets loaded with the !! prefix which ignores all loaders. But that is another can of worms (weird errors) I was not willing to open.

So here are my proposed solutions:

• Keep the exclusion and document why it's there.
• (Cleaner IMHO) Add include: paths.appSrc to the file-loader. But this could potentially break projects that use the file-loader to load files from outside paths.appSrc for whatever reason.

I'm happy to implement either one of these based on feedback.

[gaearon]

Keep the exclusion and document why it's there.

This sounds good to me.

[Furizaa]

Should be good now. Thanks for your precious weekend time guiding me through this. If there is anything else I missed then feel free pointing me to it.

[gaearon]

@EnoahNetzach Let me know if you have any comments here!

[gaearon]

I’ll get this in for now. Thank you again!

[sokra]

Instead of the exclude you could also add a empty rule matching these types

{
  test: [/\.js$/, /\.html$/, /\.json$/]
  // Don't use a loader for these types.
}

This would keep the file-loader rule focused.

[Furizaa]

Huh. Nice! Thanks for that hint. Will create a PR to change this in time. Seems much cleaner.