Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dev server stops completely when postcss-loader throws error #4514

Closed
s-shev opened this issue Jul 11, 2022 · 8 comments · Fixed by webpack-contrib/postcss-loader#593
Closed

Comments

@s-shev
Copy link

s-shev commented Jul 11, 2022

Bug report

webpack-dev-server stops completely when during rebuild postcss-loader throws an error.

Actual Behavior

I start dev server via npx webpack-dev-server and when I start typing new rule in .css webpack tries to rebuild my app but since I haven't finished typing, file contains incorrect css rule. So build fails due to postcss-loader throwing error CssSyntaxError. However that makes webpack-dev-server stop completely.

This started happening after I updated to webpack 5. Previously webpack-dev-server simply ignored failed builds and waited till webpack manages to successfully build my app.

Expected Behavior

Dev server shouldn't completely stop on error from loader but wait till webpack manage to successfully build the app

How Do We Reproduce?

I prepared repository where you can reproduce it https://github.com/s-shev/webpack-dev-server-stops. Clone it, install packages, run npm start or npx webpack-dev-server, open ./src/styles.module.css and start typing new rule: you'll see in terminal that postcss-loader throws exception and server stops.

Please paste the results of npx webpack-cli info here, and mention other relevant information

  System:
    OS: Windows 10 10.0.22000
    CPU: (16) x64 AMD Ryzen 7 5800H with Radeon Graphics
    Memory: 5.75 GB / 15.41 GB
  Binaries:
    Node: 16.14.2 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.19 - ~\AppData\Roaming\npm\yarn.CMD
    npm: 8.5.0 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Spartan (44.22000.120.0), Chromium (103.0.1264.49)
    Internet Explorer: 11.0.22000.120
  Packages:
    css-loader: ^6.7.1 => 6.7.1 
    html-webpack-plugin: ^5.5.0 => 5.5.0 
    postcss-loader: ^7.0.0 => 7.0.0 
    style-loader: ^3.3.1 => 3.3.1 
    ts-loader: ^9.3.1 => 9.3.1 
    webpack: ^5.73.0 => 5.73.0 
    webpack-cli: ^4.10.0 => 4.10.0 
    webpack-dev-server: ^4.9.3 => 4.9.3 
@alexander-akait
Copy link
Member

Oh, sounds like a regression in postcss, I don't know why they move on getter throwing errors...

@alexander-akait
Copy link
Member

Shortly - when we try to get result.root from postcss we got an error, I will fix it, but that is a little bit unexpected behaviour for getters

/cc @ai

@alexander-akait
Copy link
Member

@s-shev Please update https://github.com/webpack-contrib/postcss-loader/ to 7.0.1

@s-shev
Copy link
Author

s-shev commented Jul 11, 2022

@alexander-akait Can confirm that with postcss-loader 7.0.1 server behaves as expected. Thanks a lot!

@ai
Copy link

ai commented Jul 11, 2022

@alexander-akait PostCSS has a lazy processing for 2 cases:

  1. If you do not call await in LazyResult
  2. If you do not pass any plugins in NoWorkResult

We use it to avoid spending unnecessary resources.

@alexander-akait
Copy link
Member

@ai yeah, I undestand this, just intresting why it is on the getter... Usually I don't expect to get errors on getter...

@ai
Copy link

ai commented Jul 11, 2022

@alexander-akait for the case when you called PostCSS without plugins and then request only result.css. In this case, we can avoid parsing.

@alexander-akait
Copy link
Member

@ai I undestans this too, but before this feature we don't have an error on the getter, now we have, that is why we have this problem, sounds like a breaking change, but we already solve it, so it doesn't make sense to fix it, anyway getting errors using a method was better solution here (+ document it)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants