Integrate jest-fail-on-console in @angular-devkit/build-angular:jest

[Neizan93]

Command

test

Description

I would like to propose the integration of the jest-fail-on-console plugin into the @angular-devkit/build-angular:jest configuration. Currently, Jest does not automatically fail tests when there are console errors or warnings. This plugin helps in making tests fail when such console outputs are present, aiding in maintaining a clean and clear test output.

Describe the solution you'd like

Integrate the jest-fail-on-console utility into the @angular-devkit/build-angular:jest configuration. This would involve adding the utility as a dependency and invoking it in the appropriate setup files for Jest.

Describe alternatives you've considered

While there might be alternative solutions or workarounds, such as manually asserting console outputs in tests, integrating jest-fail-on-console would provide a standardized and automated approach, reducing the overhead for developers to manage console outputs in their tests.

• Manually asserting console outputs in tests: While this is possible, it can lead to duplicated effort and less standardized testing practices.

• Integrating Jest configuration within angular.json: Another alternative would be to integrate the Jest configuration (such as jest-config and jest-setup) into the angular.json configuration for @angular-devkit/build-angular:jest. This would provide a more seamless way to incorporate plugins like jest-fail-on-console and other customizations.

[dgp1130]

Similar to #25696, I think we'd rather avoid adding an additional dependency by default for new projects. While rejecting log statements by default can be valuable for very large projects, I suspect this would be too frustrating to newer devs to enable by default.

All that said, Angular projects should be able to opt-in to this tooling if they want to. Without #25434 it might be a little less intuitive to install in a project.

Does this package strictly need access to the Jest configuration? It looks like most of this is done by patching the global console object and then adding a conformance test in afterEach. It seems like the only Jest configuration it really uses is setupFilesAfterEnv (example). I suspect you could do the same thing with our current implementation by adding this to test polyfills. It's not really a "polyfill", so that's maybe not the ideal name, but I think something like polyfills: [..., "jest-fail-on-console"] might just work out of the box.

This approach might be a little more confusing to install, since the instructions would be to install the package and add it to test polyfills, but I don't think it's meaningfully more complicated than telling users to add the package to setupFilesAfterEnv like it already does. An ng add schematic could improve that as well. Could that be a viable path to using this package without direct access to the Jest configuration?