[key packages] Addressing Node.js CITGM failures

[dominykas]

This was brought up in the 2019-09-24 meeting issue by @Trott:

Not sure if this fits in with the package-maintenance team's goals/charter/whatever, but assistance getting things aligned in the ecosystem and Node.js 13.0.0 such that we minimize the pain of any Node.js breaking changes for end users would be 💯. Specifically, it would be great if we could get rid of as many CITGM issues there as possible.

We didn't really get a chance to discuss this during the meeting, so creating a separate issue for this:

• What can we as part of this group do to help out on v13 and future releases?
• How can package maintainers get involved?

[dominykas]

Some ideas on how to get contributions with fixes: #259 (comment)

[Eomm]

As we are suggesting to test against the LTS versions, we could suggest a setup to run the tests against the new node version that triggers warning and don't block the CI pipeline

[dominykas]

Running against, essentially, nightlies is likely too much of a budern and could produce too much noise - not sure I'd recommend that to package maintainers. But there is a need to better surface these failures when the need arises.

I think I need to learn more about existing CITGM processes :)

[Trott]

Running against, essentially, nightlies is likely too much of a budern and could produce too much noise - not sure I'd recommend that to package maintainers. But there is a need to better surface these failures when the need arises.

I think I need to learn more about existing CITGM processes :)

CITGM is run against proposed breaking changes in the Node.js master branch. Ideally, CITGM against master branch should always be green. (If a breaking change is going to break a package in CITGM, the package should be updated first before the breaking change lands. At least, that's my opinion!)

However, as of now, there are packages that are broken against the master branch. I would like those to be fixed. This would have a lot of benefits. First, it would make CITGM results much easier to interpret Right now, it requires a person to know what failures are expected. Second, it would open the door for some CITGM automation and running CITGM on release proposals. Thirdly, it would encourage us to keep the package list in CITGM up-to-date. There are likely some unmaintained packages in there, and I'm not sure it's appropriate to have unmaintained packages in there unless their usage is extremely widespread such that breaking them would break the ecosystem.