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).
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).
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.
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?
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
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
Will there be a proper solution for this “hack”? Faking the timestamp is interacting badly with the metro build system of react-native (probably it tracks if the timestamp to see if the file has been updated), so need to resolve all warnings first before a good fast-refresh is happening.
