Page Styles Break When I Change Styles in Chrome Devtools with Webpack Hmr

Broke page styles of Vue.js app (Webpack template) when live changing it in Chrome DevTools

I find another solution. Thanks to answer of @munstrocity regarding changing cheap-module-eval-source-map to eval-source-map. Unfortunately, this change didn't fix for me my styles in Chrome Dev Tools but give me good point to check.

After a bit I found, that changing cacheBusting: true, to false in config/index.js help to solve that and now it's possible to change style in Chrome Dev Tools.

// file: config/index.js

...
// If you have problems debugging vue-files in devtools,
// set this to false - it *may* help
// https://vue-loader.vuejs.org/en/options.html#cachebusting
cacheBusting: false,
...

Hope this will help anyone! :)

Issue with dev-tools style editing in Nuxt.js

on nuxt.config.js file, disable the sourceMaps for scss files with the loader property

export default {
  // ...
  build: {
    loaders: {
      scss: { sourceMap: false },
    },
  },
  // ...
}

see in ~> nuxtjs.org/api/configuration-build/#loaders

Running ng server with --hmr still causes page to reload on changes

It looks like I had to add the following in the main.ts

declare var module: any;
if (module['hot']) {
    module['hot'].accept();
    module['hot'].dispose(() => ɵresetCompiledComponents());
}

I still get the message mentioned in my original post but at least I see a different behavior. If there are any other things to tweak please let me know :)

Webpack style-loader / css-loader: url() path resolution not working

I was able to solve the problem myself. In case it could help others in the future, please find the solution below.

---

1. First of all, if you are using both postcss-loader with the postcss-import plugin, AND css-loader, turn off / delete the postcss-import plugin. You do not need more than one tool that resolves @import rules. This is not really a problem if the order of loaders is correct, but you might as well remove it.
2. In the sass-loader docs, you can read the following:

Since Sass/libsass does not provide url rewriting, all linked assets
must be relative to the output.

• If you're just generating CSS without passing it to the css-loader, it must be relative to your web root.

• If you pass the generated CSS on to the css-loader, all urls must be relative to the entry-file (e.g. main.scss).

More likely you will be disrupted by this second issue. It is natural to expect relative references to be resolved against the .scss file in which they are specified (like in regular .css files). Thankfully there are two solutions to this problem:

• Add the missing url rewriting using the resolve-url-loader. Place it before the sass-loader in the loader chain.

• Library authors usually provide a variable to modify the asset path. bootstrap-sass for example has an $icon-font-path. Check out this working bootstrap example.

I decided to follow bullet two, and add in resolve-url-loader above sass-loader in the Webpack config. It now works as expected.

My final Webpack config (for now) looks like this:

    {
      test: /\.s?[ac]ss$/,
      exclude: /node_modules/,
      use: [
        isProduction
          ? MiniCssExtractPlugin.loader
          : {
              // creates style nodes from JS strings
              loader: 'style-loader',
              options: {
                sourceMap: true,
                // convertToAbsoluteUrls: true
              }
            },
        {
          // CSS to CommonJS (resolves CSS imports into exported CSS strings)
          loader: 'css-loader',
          options: {
            sourceMap: true,
            importLoaders: 2
            // url: false,
            // import: false
          }
        },
        {
          loader: 'postcss-loader',
          options: {
            config: {
              ctx: {
                cssnext: {},
                cssnano: {},
                autoprefixer: {}
              }
            },
            sourceMap: true
          }
        },
        {
          loader: 'resolve-url-loader',
          options: {
            attempts: 1,
            sourceMap: true
          }
        },
        {
          // compiles Sass to CSS
          loader: 'sass-loader',
          options: { sourceMap: true }
        }
      ]
    },

Side Notes

1. I noticed that source map paths under "no domain" in Chrome's debugger are repeated. If anyone figures out why, please do share

2. Remember to include the below side effects in package.json, so tree shaking, which happens in production mode, does not delete the extracted css

   "sideEffects": [
   ".css",
   ".scss"
   ],

---

Related Topics