[rush] Add suppressedWarnings option

[ecraig12345]

Add an option suppressedWarnings (naming negotiable) to treat certain warning substrings as standard log messages rather than errors. This is so that if those warnings show up for reasons outside a project's control, they won't break incremental builds.

Background: In Fabric, we've increasingly been having problems with an intermittent warning [DEP0097] DeprecationWarning: Using a domain property in MakeCallback is deprecated. Use the async_context variant of MakeCallback or the AsyncResource class instead. breaking incremental builds (fabric issue). I did some investigation and figured out that this warning comes is due to the way certain packages are calling into Node's C++ layer, but I had no luck tracking down the actual problem packages. And even if I'd been able to track down the issue, it would likely have been a nightmare of getting dependencies of dependencies to upgrade before it could really be fixed.

[iclanton]

I think the list of suppressions should be treated as regular expressions instead of simple substrings.

[iclanton]

I'd remove this second paragraph.

[iclanton]

I think these should be regular expressions instead of simple substrings.

[octogonz]

Also the regex's should be anchored to match the whole "message". But see my note below...

[octogonz]

@ecraig12345 did you consider --no-deprecation?

[octogonz]

@ecraig12345 in this code:

        task.stderr.on('data', (data: string) => {
          writer.writeError(data);
          this._hasWarningOrError = true;
          // If this error matches any of the suppressed warnings from the config, write it to
          // stdout instead of stderr and don't treat the task as having a warning/error.
          if (this._rushConfiguration.suppressedWarnings.some((warning: string) => data.indexOf(warning) !== -1)) {
            writer.write(data);
          } else {
            writer.writeError(data);
            this._hasWarningOrError = true;
          }
        });

...I'm not sure that the concept of a "warning" or "line" exists at all. The data string is a chunk of buffered text. As far as I know, the string may contain the second half of a line, followed by a newline character, and then the first half of the subsequent line. It may be purely coincidence that certain popular binaries or scripts choose to flush the stream after writing each line of text.

Also, the text buffer sometimes contains color escape characters, and sometimes not. There are probably other similar technical issues that a generic stream parser may need to consider.

Up until now, Rush has carefully avoided getting involved with stream parsing. We do collect stderr and interpret it as "there were some warnings" and print it as a summary at the end, but otherwise Rush is pretty agnostic about the tasks that it orchestrates.

I wonder if there is a different approach. For example, maybe the "filtering bad messages from a tasks's output" could be made into a separate tool, and then the build task could pipe itself through that tool. This would allow the solution to be more versatile, and developed by a larger audience, and it would give more fine-grained control over which filters are applied to which processes.

On the other hand, we could also just go and fix the bad task that's doing deprecated stuff. (It may be easier than you estimated.)

Just something to think about...

[ecraig12345]

@ecraig12345 did you consider --no-deprecation?

How would I pass that to rush build? Would it have to be added to every single package's npm build script?

[octogonz]

did you consider --no-deprecation?

How would I pass that to rush build? Would it have to be added to every single package's npm build script?

@ecraig12345 Yes, but that is sort of what you want, right? Typically a monorepo is going to have a standard toolchain that is shared by all the projects. On the other hand, if different projects have custom toolchains, then in general maybe we would want to suppress different warnings for different toolchains.

How selective are you guys about the particular warnings that get suppressed? I noticed there is also a NODE_NO_WARNINGS=1 environment variable that will suppress all warnings. We have been wanting to improve how Rush passes environment variables down to the processes that it executes, so that's also an option. It seems like a "battle axe" approach. On the other hand, you could argue that if Node.exe is going to be intruding on every script's personal STDERR stream, Node should provide a lot more fine-grained control for suppressing these warnings.

(It might also be useful to try a little harder to investigate and fix the underlying issue, since I haven't seen these issues arise very often. Maybe we can just upgrade a bad package, or remove it, or downgrade NodeJS if the code base isn't ready for it yet, etc.)

[octogonz]

I'm going to close this PR for a few reasons:

• The implementation is incomplete, because as mentioned above, it does not parse newlines
• Ideally each warning should be investigated and then individually suppressed (rather than categorically suppressing all warnings)
• This particular warning occurs because just-task is doing something that's incompatible with Node 10. If it isn't easy to fix, then just-task can suppress it easily as explained here
• If someone disagrees with my philosophy (i.e. wants to categorically suppress all warnings without investigating them individually), that can already be done using the NODE_NO_WARNINGS environment variable

@ecraig12345 @iclanton

[octogonz]

(Of course if you disagree or think I missed something, feel free to reopen this. I'm just trying to trim down the queue. :-) )