3.2.2 breaks resolve-url loader

[Hufschmidt]

Issue

It seems like either commit e0ce2b4 breaks resolve-url loader, or there is something wrong with my webpack config (working flawlessly with 3.2.1).

Upon switching to sass-loader 3.2.2 from 3.2.1 (tested working) I get the following warning during bundling:

 WARNING in ../~/css-loader?sourceMap!../~/resolve-url-loader?sourceMap!../~/sass-loader?sourceMap!./scss/ionic.scss

  resolve-url-loader cannot operate: source-map error
  cannot establish a common base path for all sources in the incoming source-map

Additionally, relative url(...) paths (eg. fonts used by ionicons) produce error because they can not be resolved anymore:

 ERROR in ../~/css-loader?sourceMap!../~/resolve-url-loader?sourceMap!../~/sass-loader?sourceMap!./scss/ionic.scss

 Module not found: Error: Cannot resolve 'file' or 'directory' ../fonts/noto-sans-bold.ttf in /some/absolute/path/to/project/src/scss
  @ ../~/css-loader?sourceMap!../~/resolve-url-loader?sourceMap!../~/sass-loader?sourceMap!./scss/ionic.scss 6:393227-393265 6:393456-393494

The later is obviously emited because resolve-url has problems with the source-maps generated with sass-loaders current settings.

Webpack-Config

{
  context:                helpers.root('src'),
  entry: {
    'app':                './app.ts'
  },
  output: {
    filename:             '[name].bundle.js',
    sourceMapFilename:    '[name].bundle.map',
    chunkFilename:        '[id].chunk.js'
    path:                 helpers.root('www')
  },
  resolve: {
    extensions:           [ '', '.ts', '.js', '.scss' ],
    root:                 helpers.root(),
    modulesDirectories:   ['node_modules']
  },
  module: {
    loaders: [
      {
        test:             /\.ts$/,
        loader:           'awesome-typescript-loader',
        include:          [ helpers.root('src') ]
      },
      {
        test:           /\.scss$/,
        loader:         'style-loader!css-loader?sourceMap!resolve-url?sourceMap!sass-loader?sourceMap',
        include:        [ helpers.root('src/scss'), helpers.root('node_modules') ]
      },
      {
        test:                 /\.(svg|woff|woff2|eot|ttf)(\?.*$|$)/,
        loader:               'file-loader',
        include:          [ helpers.root('src'), helpers.root('node_modules') ]
      }
    ]
  },
  sassLoader: {
    includePaths: [
      'node_modules/ionicons/dist/scss/'
    ]
  },
  plugins: [
    new PluginHTML({
      template:             './app.html',
      inject:               'body',
      chunksSortMode:       'dependency'
    })
  ],
  devtool:              'cheap-module-eval-source-map',
  debug:                true
};

Full config

Details

In my main entry-point app.ts I do a require('./scss/ionic.scss');. Inside I fine-tune some scss variables and then @import '~ionic-angular/ionic.scss' code. The same error happens btw. when directly including ionic-angular/ionic.scss via require('ionic-angular/ionic.scss') instead.

The transpiled css code will then be inserted into a style-tag globally by the final style-loader, where it is available to be used by ionic components and directives.

Of course I could always fix this issue by setting $font-path: '../../node_modules/ionic-angular/fonts' inside my ./scss/ionic.scss file, but up until 3.2.2 the resolve-url loader was able to resolve relative url(...) paths for me, which I feel was a great boon. :(

[jhnns]

Yes, this was an unintentional breaking change with 3.2.2 (see #250). I've deprecated this version and published this change with 4.0.0.

@bholloway and I will sort it out, but he is currently on vacation, so that may take a while.

[toverux]

The 4.0.0 release didn't fixed the problem for me. With 3.2.1, the project builds, with 3.2.2 I get:

WARNING in ./~/css-loader!./~/resolve-url-loader!./~/sass-loader?sourceMap!./~/bootstrap-loader/lib/bootstrap.styles.loader.js!./~/source-map-loader!./~/source-map-loader!./~/bootstrap-loader/no-op.js
  resolve-url-loader cannot operate: source-map error
  EACCES: permission denied, scandir '/lost+found'

Same with 4.0.0.

[Hufschmidt]

As far as I understand, breaking changes where moved from 3.2.2 (marked deprecated) to 4.0.0, so you should still be able to do "^3.2.0" in your package.json without installing incompatible 3.2.2 release.

Sidenote: EACCES: permission denied, scandir '/lost+found' indicates you might have another problem.

[jhnns]

That's correct, 3.2.2 and 4.0.0 contain the breaking commit. However, 3.2.2 was deprecated so I would expect that npm won't install it when specifying ^3.2.0 (but I don't know that for sure).

[judewang]

npm install sass-loader@^3.2.0 --save-dev will install v3.2.2 with a kindly warning lol.

[jhnns]

@judewang thanks for pointing out.

Now I've published sass-loader@3.2.3 which is identical to 3.2.1. However, when you run npm i sass-loader, you will get 4.0.0 because it's still tagged as latest.

[mlegenhausen]

Why do you not unpublish 3.2.2? It had saved me some time.

[jhnns]

npm unpublish does only work if there are no dependent packages. Furthermore, if people happened to install 3.2.2 with --save-dev, it won't be available anymore. So, this was most unobtrusive way imho.

[mlegenhausen]

I read you can contact the npm team if something like this happens (I think after 24 hours you can unpublish any package anymore).

IMHO I am also not a fan of unpublish, cause I like the immutable nature of npm packages, but failing early on package installation is better than failing somewhere in your build process where it is harder to debug and everyone that uses exact versions (like me) wants this feedback, before they build their software with a broken version.

[jhnns]

I agree, but unpublish would have been too late for you anyway. So I think the current solution is the best in all cases.

[mlegenhausen]

Sure and of course thank for the quick fix :)