YN0002 performance consequences?

[ghost]

I have over one thousand YN0002 emitted for a project. Through a fairly obnoxious manual process which needs to be repeated for each rank of the dependency graph, I am able generate a packageExtensions declaration for all the missing peer dependencies. Some of them are external packages, and some are internal to the monorepo. Sure, they ought to be corrected.

Some of these fully resolved YN0002s convert to YN0060s which are more nuanced to fix. We might want to go through this effort, but it doesn't seem like the kind of thing we'll be able to fix once and for all; any time an external package gets upgraded, it could shift the whole scenario and create new YN0060s to investigate, I figure.

I basically understand what imperfection YN0002 is complaining about, but I'm not sure what kind of consequences it is trying to protect me from. My application currently has no known runtime bugs related to undeclared peer dependencies or mismatched version expectations. If I fix these, YN0060s I would expect some regression risks.

Does a YN0002/YN0060 situation cause any significant build performance problems related to module resolution or bundle bloat?

[JasonKleban]

Anybody?

Related: #3629

[JasonKleban]

Checking in on this. These warnings seems to be unsilencable and noise up the build logs