Lerna root "package-lock.json" not updated during child package renovation.

[abernix]

What Renovate type are you using?
Renovate GitHub App

Describe the bug
I'm going to try to make a reproduction for this, but I believe I've seen an issue in a Lerna 3 monorepo which uses file: reference specifiers and does not have package-lock.json files in the nested packages. For example, the Lerna monorepo looks roughly like:

- package.json
- package-lock.json
- packages/
  - packageA/
    - package.json

In the case that I'm analyzing right now — which happened in a private repository — Renovate updated a package listed in the dependencies of packageA's package.json. Again, that packageA does not have a package-lock.json. In the past, this type of renovation has resulted in the updating of the root's package-lock.json, as is the case with this public issue which roughly represents the same type of update: apollographql/apollo-server#2004.

On this recent change though, the only changes to the root's package-lock.json were the toggling of the "optional": true attributes (which I know we're all too familiar with).

This last bit indicates to me that package-lock.json was updated, but just the update to the appropriate package didn't get caught, for whatever reason.

Did you see anything helpful in debug logs?

I didn't see an anything helpful, but I believe the job log is 49906094 and the package was apollo-graphql.

To Reproduce
I can work on this next week, if it's helpful.

Expected behavior
In a Lerna 3 monorepo, when a sub-package's dependency is updated, the root's package-lock.json gets updated as well. To be honest, the only reason I have this expectation is that it's happened in the past. This is not what I would expect during a normal npm install in a subdirectory of a Lerna monorepo without also running npm install at the root afterward (to update the package-lock.json)

[rarkins]

@abernix a reproduction repo would definitely be appreciated here, if you get the time next week

[abernix]

Yup! We don't have these types of renovations on our repository very often.
Just dug around some more and saw that apollographql/apollo-server#2233 seems to have also worked as expected.

Also, the affected package in that job log was apollo-graphql.

[HonkingGoose]

@rarkins I think we still need a reproduction repository here to make progress on this issue?

[github-actions]

Hi there,

The Renovate team needs your help! To fix the problem, we first need to know exactly what's causing the bug. A minimal reproduction help us to pinpoint the exact cause of the bug.

To get started, please read our guide on minimal reproductions to understand what is needed.

We may close the issue if you have not provided a minimal reproduction within two weeks. If you need more time, or are stuck, please ask for help or more time in a comment.

Good luck,

The Renovate team

[github-actions]

When a bug has been marked as needing a reproduction, it means nobody can work on it until one is provided. In cases where no reproduction is possible, or the issue creator does not have the time to reproduce, we unfortunately need to close such issues as they are non-actionable and serve no benefit by remaining open. This issue will be closed after 7 days of inactivity.

[github-actions]

This bug report has been closed as we need a reproduction to work on this. If the original poster or anybody else with the same problem discovers that they can reproduce it, please create a new issue, and reference this issue.