[rush] filter specific warnings during CI

[robertf224]

Just started using the new Next.js app directory in our Rush repo. The feature is listed as "experimental" in Next.js, and they emit this warning during builds:

Because of the warning, our Rush CI build now starts to fail. There's an upstream issue tracking this, but obviously not predictable when it'll be addressed. We obviously could use Rush's allowWarningsInSuccessfulBuild as an escape hatch here, but I'd rather not sacrifice the integrity of our entire job based on one warning in one dependency.

It would be cool if there was a way to filter out / allow specific warnings during the job. There's obviously a balance here because the reason the setting exists in the first place is to prevent developers from ignoring warnings, but there is a difference between warnings you're fine with / have accepted risks for (i.e. this one in our case) and warnings you're seeing for the first time which should actually fail your job. The practical alternative of turning off warnings for the entire repo seems worse here, and assuming there were some configuration file for allowed warnings, a team could use CODEOWNERS to add technical controls against accepting every warning, and could leave comments that explain the reason for filtering the warning and tracking upstream issues.

Intuitively seems like something that could/should be delivered as a Rush plugin (related in spirit to this open Heft plugin PR). This won't actually work (couldn't find a real way to plug into the Terminal for a Rush session on first glance) but would imagine code looking something like this:

[iclanton]

Yeah ideally you could suppress that specific warning with an environment variable or some other flag.

This does seem like a useful feature. This could go into a plugin (we've been expanding the plugin API surface as people have written plugins that need more APIs), or it could go into the rush-project.json file.

Would you be interested in putting this together?

[robertf224]

yeah I'm happy to build it + can put together a proposal. could use guidance here on a gut check around shipping it as a plugin or as a core feature -- if it's core it's obviously easier to manipulate the terminal output, whereas if it's a plugin (something like my pseudo-code above) we'll need some generic way for plugins to add some sort of processor to a stack of terminal output processors (which probably requires some changes to the existing Terminal API). plugin route might not be worth the squeeze if there aren't any other real use-cases for intercepting/manipulating terminal output