This is my thinking as well. I’m in favour of this change, if we can have a “dev” mode (which has been discussed previously) that reverts back to warnings as warnings.
If you have so many warnings that you can miss new critical ones, having the compiler enforce warning-as-error in production may be a difficult change to adopt 
The major motivation is to help editor always report warning/errors reliably.
Other parts are trade offs we have to make, note we don’t close the door like go, you can always disable warnings if you don’t want to get it blocked
Is there not a solution to both have good errors and good warnings?
To me only having warnings correctly reported in a clean build is not a big problem. This solution is worse when it comes to developer experience. It sucks when developing to have to compiler not compile because you are not using a variable right now. So I would encourage to either find a solution that has proper warnings OR if that’s too tricky with the current compiler, it’s not a big problem we are facing at the moment (warnings generally don’t break things).
I would be happy to hear if you have a better solution for reliable editor error reporting
Fully agree with @jfrohlich.
During development
At Ahrefs, we use "warnings": {"error": "+A-d"}, by default in all the frontend codebase, so what Bob proposes is aligned with our setup. This configuration forces us to go to some extra lengths sometimes to remove warnings from generated code (e.g. https://github.com/ahrefs/atd/pull/214) but we think it’s worth it. In our experience, it is much cheaper to fix a warning in context, while one is editing the file, rather than waiting for CI to report the error way later in time.
It’s great to also leave a work around / escape hatch if needed.
I would be happy to hear if you have a better solution for reliable editor error reporting
@Hongbo if the editor extension somehow called bsc.exe on the currently edited file individually, then warnings would not be lost between runs, right? (I understand this would involve having the editor somehow reading from build.ninja… but just curious if it’d be a viable approach).
We’re exploring something to improve the user experience in warn-as-error, e.g, keep the build going as far as it can to list all errors in one build.
Only the build system has a global view of the repo to provide reliable error diagnostics
Unless I misunderstood–the compiler wouldn’t enforce anything different for existing codebases. We are talking about warning and error settings for new codebases only, i.e. changing the recommended bsb -init templates. But maybe @Hongbo can confirm.
I will write a post about the new design, good news is that we can achieve the best of bost worlds when we own both the compiler and build system
After some hacks, I think we can still generate js files even with non-critical errors, however, we need fake the time stamp of generated js files to notify it’s dirty. (it works on my OS, need test Windows)
In this case, would it be better?
This is excellent news, thanks a lot for your efforts! 
I am not sure what you mean by faking the timestamps though, could you explain that in more detail?
Let me know if you would like me to test someting! 
Amazing, Bob. Thank you!
I didn’t have time to respond to the announcement thread yesterday, I can understand why errors are better from a build system perspective but I definitely rely on continuing to generate JS with non-critical errors. I will put up with any hacks required to do so and I support this move.
A future IDE improvement could even flag non-critical errors as warnings in the IDE 
we set mtime of generated js file to be 0 and change the build system to think it is non-exist. Will publish a dev release for testing
bs-platform@8.3.0-dev.2 is available for testing
The obvious difference (desired behavior):
The non-obvious difference:
Sounds like the perfect compromise. I also like the non-zero exit code, to fail the CI when there are warnings, but still have a good dev experience.
I have to say I’m really impressed by the work you’ve done @Hongbo, managing to get the best experience for both use cases. It must be really hard to satisfy everybody and listening to feedback must sometimes feel overwhelming but that leads to great solutions, thank you a lot for taking the time! We not only have the best alt-js language, we also have a great community and it’s really cool to be able to benefit from it
Just tested it on a large code base (I’m on OSX): The hack works like a charm. An error is reported but the file is built. Gotta love the wizardry 
Just tested it, too, and it worked perfectly. This is a huge relief! Thanks again for your awesome work @Hongbo! 