Config-help: Some Questions regarding multiple independent package.json files

[karfau]

Which Renovate are you using?

WhiteSource Renovate App

Which platform are you using?

GitHub.com

Have you checked the logs? Don't forget to include them if relevant

In don't know how to get them.

What would you like to do?

I have a repository that contains two package.json files:

1. for a set of legacy angular SPAs that we are glad are still working as is. (It didn't get dependencies updated for quite a while and whenever we tried we needed to revert. There is not enough test coverage to be sure an update will work.)
2. for react apps that we want are able to integrate in the angular ones.

Since we want to be extra careful about updating, I configured masterIssue & masterIssueApproval as part of the "Configure Renovate" PR. Since the PR complained:

and I actually don't plan to change the "bower related things", I added the following to my config:

  "packageRules": [
    {
      "paths": ["package.json"],
      "rangeStrategy": "replace",
      "excludePackagePatterns": ["@bower_components\/.*"]
    }
  ]

To my surprise the master issue was already created before landing the PR (not sure if that is the expected behavior):

• in it's "Open" section

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

it lists all those @bower_components updates I told it to exclude.

So here are my questions:

• Is there a way to tell the two package.json files apart inside the master issue? (Or use different master issues per package.json?)
• Is there a way to disable updates for the root level package.json without disabling the other one?

I would be happy about any reply / questions, would love to figure this out.

(I searched the existing issues and checked the related issues mentioned by github, but it didn't help me.)

[rarkins]

• Is there a way to disable updates for the root level package.json without disabling the other one?

  "ignorePaths": ["package.json"]

This will cause it to not even be parsed, so Renovate won't know what's in it, let alone try to look up any.

Alternatively to ignore those bower components:

  "packageRules": [
    {
      "paths": ["package.json"],
      "packagePatterns": ["@bower_components\/.*"],
      "enabled": false
    }
  ]

The rule you tried that is similar to this essentially "did nothing" because the default rangeStrategy is "replace". So it selected all packages in package.json not matching bower_components/* and then.. set their rangeStrategy to be "replace". It also therefore did nothing to change the default behaviour (which is also "replace") for the bower components themselves.

If you want to disable bower components completely but otherwise get some visibility into upgrades in package.json, and have them somewhat distinguishable, then try this:

  "masterIssue": true,
  "packageRules": [
    {
      "paths": ["package.json"],
      "packagePatterns": ["@bower_components\/.*"],
      "enabled": false
    },
    {
      "paths": ["package.json"],
      "commitMessageSuffix": "[legacy]",
      "masterIssueApproval": true
    }
  ]

"[legacy]" can be anything you want. It will be added to the commit messages and PR titles so then you would be able to distinguish them from other PRs within the master issue.

[karfau]

Oh, that makes sense, ..., in a way. Thx.
(Is this "algorithm" documented in some place that I didn't spot yet?)
Will try that and either come back with more questions or close the issue.

[karfau]

Not sure why my reply is worth a :-1:, but the suggestion you gave didn't work the way I expected:
Any time I add one of your suggestions containing a reference to package.json it seems to effect all files with that name, so renovatebot also stops looking into the one for the react app (it's inside a folder named scr-react).

I have tried also different variations like ^package.json or ./package.json to only consider the root level one but nothing worked.

The only way that works for me so far is to "highlight"(commitMessageSuffix) and split(branchPrefix) the react part from anything else.

If that is not what you expected, I can try to create a public repo with that scenario, if this is what helps.

[viceice]

@karfau The 👎 means that the algorithm is not documented. It would be nice to create a public sample repo for futher help.

[rarkins]

The matching approach we have may be too fuzzy. But if you have only two package.json files then we might be able to “reverse” the logic from earlier and apply rules to the nested package file instead, eg backend/package.json or whatever it’s called.

[karfau]

Applying the suggestion from above results in this output
https://github.com/karfau/renovate-config-help-519/issues/2

(Using an image here since trying different approaches will of course change the issue over time.)

[rarkins]

It seems like the repo/PR you're pointing to cannot be the same that you took a screenshot from, because it's still in onboarding phase?

[karfau]

If you follow the link you will see that it actually is the case.
And I mentioned that earlier, as part of my initial question(s):

To my surprise the master issue was already created before landing the PR (not sure if that is the expected behavior): ...

[rarkins]

Oh, wow. No, I missed what you meant by that. Definitely not meant to happen, and the "Open" categorization is wrong too anyway (but irrelevant considering it's not meant to exist).

BTW can you clarify what you decided you want the functionality to be? e.g. do not ignore package.json completely - instead have all PRs require approval there first, while letting the nested package.json PRs come without approval?

[karfau]

I would love to be able to configure "stuff" just for the top level package.json file without an impact on other package.json files, e.g. in my case:

• "masterIssueApproval": true (while it's false for everything else)
• "commitMessageSuffix": "[LEGACY]"
• "branchPrefix": "renovate/legacy/"
• "rangeStrategy": "replace" (while everything else is getting pinned)
  this way all the configuration from the top level should still be applied to all other files.

(The reverse approach you suggested above is limited/ to verbose, since I'm now using the top level config to target the root level one, but it of course also impacts all things renovate detects, like .nvmrc files, that are not configured additionally...)

[viceice]

Ok, looks like we have a bug. We can't target a root file only with packageRule.paths as it also matches file path ending with that configured path.

[viceice]

https://github.com/renovatebot/renovate/blob/d2a67bb38e4ea8ecea82cc050f1f902f0814ae66/lib/util/package-rules.ts#L82-L92

[viceice]

Maybe you can workaround with using a negated minimatch expression.

!**/package.json

[viceice]

Or {package.json}

[karfau]

The {package.json} pattern doesn't work as expected, I think it is not matching anything, since it also lists the @bower_components again (and doesn't add the commitMessageSuffix):

---

I wont try the negated expression since it's not so different from what I'm using now (in the original repo) where I set the rules for the root package.json on the top level and add reset to default value for the other file.
But in my personal opinion the negated expression is even more confusing to read/maintain.

[viceice]

yes, but the negated expression is the only way to go, if you don't want to have to override the rule for other files

[karfau]

Sorry, I don't get that: why would the negated expression not override the rules for other files?

[karfau]

(I applied the negated expression, but it doesn't seem to work either, the issue didn't change compared to the {} pattern.)
Not it changed and it clearly shows that the negated expression also effects other files (like .nvmrc):

chore(deps): update node.js to 8.17 [!**/package.json]

[viceice]

can you please add me as contributor to your repo, then i can view the renovate logs.

[viceice]

Thanks, if played a bit with minimatch and '!*/package.json' is the way to go, because ** also matches nothing it will not apply the rule to root package.json. I've applied the required change to your config.

[karfau]

It still matches the .nvmrc files, but I get your idea to find a patter that excludes every other file.
And this pattern would need to be maintained whenever a file is added that would be treated by renovate or renovate adds a feature... It's clearly just a workaround but I agree it might be more explicit then what I use now. Also in case it is fixed, the config would only need to get rid of the pattern.

[viceice]

yes, because .nvmrc files are enabled by default. you have to explicit disable all files you do not like to be renovated

[viceice]

for .nvmrc you can simply disable it with

{
  "nvm": { "enabled": false }
}

[karfau]

It looks like my comment was not well articulated. I want renovate to care about everything it can.
That's why I would need to come up with a pattern excluding everything beside the top level pkg.json

[viceice]

ok, let me know if you need more help

[karfau]

What are the chances this will be fixed/changed?
(Maybe allowing the pattern to begin the path with ^ to prevent the usage of .includes would be a way without breaking existing things.)

[viceice]

@rarkins What do you think about the ^ startsWith char?

[rarkins]

I think when it comes to files, we have usually stuck with glob patterns instead of regex. The problem here is - for legacy reasons - we also have a dumb string match alternative too:

    const isMatch = paths.some(
      rulePath =>
        packageFile.includes(rulePath) ||
        minimatch(packageFile, rulePath, { dot: true })
    );

I would like to deprecate this, but it's hard not to disrupt people who already have rules depending on it. Maybe we could introduce an option like "pathGlobOnly" defaulting to false and let people enable it for glob-only matching, which I think then would behave more sensibly.

BTW I wondered if it might be possible to play around with globs to break the string match, but I haven't had time to respond yet. I an optimistic that +(package.json) would match only package.json and not any of the subdirectories.

[viceice]

+(package.json) does the trick

[karfau]

Thx a lot!

I agree that having an option that clearly communicates what will happen is more sensible than introducing some RegEx syntax.

Looking forward to it.
Should we close this issue and create one for pathOnlyGlob? (I guess in https://github.com/renovatebot/renovate, would love to know when it happens. )

[viceice]

feel free to open the issue

[rarkins]

Actually I'm not certain we need it, if instead we just document that a partial string match is also done so wrap a glob in +(...) to enable glob-only matching. Someone would need to read the documentation anyway, and this doesn't seem too burdensome.

[karfau]

You can of course also close that request this way.
It was you that stated you would like to deprecate that behavior, so you know best why.
In case this needs to be deprecated an option to disable it is already the first good step in the right direction, that would also allow to see how big of an impact the deprecation might have.