Increase packageRules logging verbosity

[rarkins]

Tell us more.

It's a common case where:

• some package rule or set of rules isn't behaving as the user expects
• the user wants to know "why isn't it matching" etc

The challenge is, there's too many non-matches. That would be like asking for logs for why any row doesn't match an SQL SELECT query.

But we have less matches than non-matches, so it's more feasible to log when something matches, and users can then work out that it didn't match.

One way to reduce this even more, is to think: it doesn't matter that a package rule is matched and applied. What matters is when a package rule is matched, applied, and changes something. That way if a simple rule matches every single time applyPackageRules() is applied, then we log only the first time.

So what I'd like to do is log a message whenever a package rule is matched/applied and it changes data. the question is: how much metadata should be logged along with it?

Here's another idea: use "coordinates" for both the config and the package rules. Once a config is resolved, and list of packageRules is static, and ordered. So we could use a simple "index" starting at 0 for the rules. Users could find out the list of rules from printConfig=true. For dependencies, at our top level is the manager, then we have an array of package files, then an array of dependencies, then an array of updates. So if the first dependency in an npm package file had a non-major update available, it's coordinate would be npm.0.0.0 where the three zeroes stand for:

• first package file
• first dependency
• first update

So the smallest log message could be like [state=datasource-merge] npm.0.0 matches packageRules.0 and changes fields: groupName, groupSlug. Would this be feasible/scalable?

[viceice]

Sounds interesting.