Loading `@import`-ed CSS files breaks Webpack Hot Reloading

[abhchand]

Bug report

Actual Behavior

If you make an edit to an @import-ed CSS file that results in an error (e.g. invalid CSS), webpack hot reloader no longer detects further changes in that file - even if you correct or undo the edit (CTRL-Z). You need to restart webpack for it to start detecting the file again.

This is only in the specific scenario of a breaking change. Any valid change continues to be detected by hot reloading.

This is also specific to only @import-ed files. Any change to a top-level file that is not imported by another CSS file continues work with hot reloading.

Expected Behavior

Webpack Hot Reloader should continue detecting updates to the previously edited file. If the error is corrected, it should recompile and emit the successful file.

How Do We Reproduce?

Here is a repository to reproduce it: https://github.com/abhchand/webpack-postcss-hmr-issue-reproduction. This repo uses postcss to run Tailwind CSS.

1. Clone the repo
2. Run yarn install, then yarn run start
3. Open http://localhost:3035/

You'll notice there are 2 CSS files - main.css and imported.css. The second one is @import-ed by the first.

You can reproduce the following scenarios:

action	result
In main.css, make some breaking change (e.g. change tw:h-9 to tw-h-9)	🟢 Hot reloading should detect the change and present the error
In main.css, correct the above breaking change	🟢 Hot reloading should detect the change and rebuild the file
In imported.css, make some breaking change (e.g. change tw:border-green-500 to tw-border-green-500)	🟢 Hot reloading should detect the change and present the error
In imported.css, correct the above breaking change	🔴 Hot reloading does not detect the change and remains in error.

The only way to fix the last scenario is to restart webpack.

Please paste the results of npx webpack info here

$ npx webpack info

  System:
    OS: Linux 5.15 Ubuntu 20.04.6 LTS (Focal Fossa)
    CPU: (12) x64 Intel(R) Core(TM) i7-10750H CPU @ 2.60GHz
    Memory: 7.60 GB / 15.36 GB
  Binaries:
    Node: 18.20.7 - ~/.nvm/versions/node/v18.20.7/bin/node
    Yarn: 1.22.22 - ~/.yarn/bin/yarn
    npm: 10.8.2 - ~/.nvm/versions/node/v18.20.7/bin/npm
  Browsers:
    Chrome: 117.0.5938.132
  Packages:
    babel-loader: ^8.1.0 => 8.4.1
    css-loader: ^4.2.0 => 4.3.0
    html-webpack-plugin: ^5.5.0 => 5.6.3
    postcss-loader: ^7.0.1 => 7.3.4
    webpack: ^5.74.0 => 5.98.0
    webpack-cli: 4.10.0 => 4.10.0
    webpack-dev-server: ^4.11.1 => 4.15.2

[alexander-akait]

It is an interesting problem, and I wouldn't say that the problem here is in webpack, why does this happen:

1. When you compile first time without broken code (i.e. you don't have errors), we use this logic - https://github.com/webpack-contrib/postcss-loader/blob/master/src/index.js#L191 and all @import's after tailwindcss plugin are passing to our loader:

i.e. result.messages:

[
  {
    type: 'dependency',
    plugin: '@tailwindcss/postcss',
    file: '/cwd/webpack-postcss-hmr-issue-reproduction/node_modules/tailwindcss/index.css',
    parent: '/cwd/webpack-postcss-hmr-issue-reproduction/src/main.css'
  },
  {
    type: 'dependency',
    plugin: '@tailwindcss/postcss',
    file: '/cwd/webpack-postcss-hmr-issue-reproduction/src/other.css',
    parent: '/cwd/webpack-postcss-hmr-issue-reproduction/src/main.css'
  },
  {
    type: 'dependency',
    plugin: '@tailwindcss/postcss',
    file: '/cwd/webpack-postcss-hmr-issue-reproduction/tailwind.config.js',
    parent: '/cwd/webpack-postcss-hmr-issue-reproduction/src/main.css'
  },
  {
    type: 'dependency',
    plugin: '@tailwindcss/postcss',
    file: '/cwd/webpack-postcss-hmr-issue-reproduction/src/App.jsx',
    parent: '/cwd/webpack-postcss-hmr-issue-reproduction/src/main.css'
  },
  {
    type: 'dependency',
    plugin: '@tailwindcss/postcss',
    file: '/cwd/webpack-postcss-hmr-issue-reproduction/src/index.jsx',
    parent: '/cwd/webpack-postcss-hmr-issue-reproduction/src/main.css'
  },
  {
    type: 'dependency',
    plugin: '@tailwindcss/postcss',
    file: '/cwd/webpack-postcss-hmr-issue-reproduction/src/App.jsx',
    parent: '/cwd/webpack-postcss-hmr-issue-reproduction/src/main.css'
  },
  {
    type: 'dependency',
    plugin: '@tailwindcss/postcss',
    file: '/cwd/webpack-postcss-hmr-issue-reproduction/src/index.jsx',
    parent: '/cwd/webpack-postcss-hmr-issue-reproduction/src/main.css'
  },
  {
    type: 'dependency',
    plugin: '@tailwindcss/postcss',
    file: '/cwd/webpack-postcss-hmr-issue-reproduction/src/other.css',
    parent: '/cwd/webpack-postcss-hmr-issue-reproduction/src/main.css'
  },
  {
    type: 'dependency',
    plugin: '@tailwindcss/postcss',
    file: '/cwd/webpack-postcss-hmr-issue-reproduction/src/main.css',
    parent: '/cwd/webpack-postcss-hmr-issue-reproduction/src/main.css'
  },
  {
    type: 'dir-dependency',
    plugin: '@tailwindcss/postcss',
    dir: '/cwd/webpack-postcss-hmr-issue-reproduction/src',
    glob: '{*,**/*.css,**/*.js,**/*.jsx}',
    parent: '/cwd/webpack-postcss-hmr-issue-reproduction/src/main.css'
  }
]

So webpack starts to watching these files/directories/globs and HMR works fine.

Webpack itself does not see any nested @import url() in your case, because the tailwindcss plugin generates one big CSS file without any @imports.

But when you make something critical change (i.e. in your case tw-border-green-500 doesn't exist) - tailwindcss throws an error https://github.com/webpack-contrib/postcss-loader/blob/master/src/index.js#L125 without any additional information about dependencies and webpack can't understand what need to watch (we should update watching list from scratch on every rebuild otherwise we will have a lot of watchers and memory problems).

/cc @adamwathan Is it possible to pass dependencies along with error (maybe error.dependency, error.buildDependency/etc?) even when tailwindcss has a critical error, like we have for a normal build - https://github.com/webpack-contrib/postcss-loader/blob/master/src/index.js#L191, example of the critical error (in this issue) -

Error: Cannot apply unknown utility class: tw-border-green-500

Alternative solution make some errors is not critical, using warning, it seems to me that this is not a critical error in itself, since the construction of the CSS is still possible (just without @apply) along with the generation of a warning. Most likely other bundlers are also experiencing this problem.