feat(pub): Support updating lock files

[zeshuaro]

Changes

Add support to also update pubspec.lock when a Pub dependency is updated

Context

• Closes Renovate not updating pubspec.lock #6049
• Closes feat(pub): Support updating lock files #18412
• Continuation of feat(pub): Support updating lock files #18412 as the author mentioned that they don't time to finish the work
• The original commit on the PR is retained, I only added one additional commit to address the comments outlined here

Documentation

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please tick one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests but ran on a real repository, or
• Both unit tests + ran on a real repository
  • Sample PR with the lock file being updated - Update dependency firebase_core to v2.3.0 - autoclosed barriot/r0#6

[viceice]

needs tests for install and docker mode. checkout cargo or nugget manager for samples

[zeshuaro]

Docker mode tests

Hopefully I'm on the right direction for the docker mode tests. I tracked down that we probably need to update allToolConfig in containerbase and define the tools Dart and Flutter.

For Flutter, I think the config would be something like this, which seems to be working:

flutter: {
  datasource: 'flutter-version',
  depName: 'flutter',
  versioning: npmVersioningId,
},

But for Dart, we don't have a data source for it, so I think we would need to add a new data source for Dart. Potentially something similar to this issue: #12820. Would you be able to confirm? If this is the case, I'm also happy to work on adding a data source for Dart.

Install mode tests

For the install mode tests, I've updated the GlobalConfig but it's still not running in install mode (the exec snapshot doesn't contain the install-tool command). Is there some other config that I need to specify?

Test

it('supports install mode', async () => {
  GlobalConfig.set({ ...adminConfig, binarySource: 'install' });
  const execSnapshots = mockExecAll();
  fs.getSiblingFileName.mockReturnValueOnce('pubspec.lock');
  fs.readLocalFile.mockResolvedValueOnce('Old pubspec.lock');
  fs.readLocalFile.mockResolvedValueOnce('New pubspec.lock');
  expect(
    await pub.updateArtifacts({
      packageFileName: 'pubspec.yaml',
      updatedDeps: [{ depName: 'dep1' }],
      newPackageFileContent: 'sdk: flutter',
      config,
    })
  ).toEqual([
    {
      file: {
        type: 'addition',
        path: 'pubspec.lock',
        contents: 'New pubspec.lock',
      },
    },
  ]);
  expect(execSnapshots).toMatchObject([
    { cmd: 'install-tool flutter 3.3.9' },
    { cmd: 'flutter pub upgrade' },
  ]);
});

[rarkins]

Yes on allToolConfig. Consider semver versioning instead of npm if you don't need ranges, or keep as npm if you need npm's range syntax.

For Dart, you could maybe use https://github.com/dart-lang/sdk/tags although you want to make sure that it matches https://github.com/containerbase/base/blob/7c5021bf3f9c39e6513fe932becd52ee349057d8/src/usr/local/buildpack/tools/v2/dart.sh#L16

[zeshuaro]

For Dart, you could maybe use https://github.com/dart-lang/sdk/tags although you want to make sure that it matches https://github.com/containerbase/base/blob/7c5021bf3f9c39e6513fe932becd52ee349057d8/src/usr/local/buildpack/tools/v2/dart.sh#L16

I remember Google often pushes the new tag first but then uploads the SDK to their storage site a few days later (this happened for Flutter at least). So it seems like a new data source for Dart would be preferable?

[rarkins]

Yes, it would be preferable

[zeshuaro]

Sorry if you received a couple of review re-requesting, GitHub doesn't let me to re-request both of you for some reasons.

[HonkingGoose]

Sorry if you received a couple of review re-requesting, GitHub doesn't let me to re-request both of you for some reasons.

There's a "refresh" icon you can use to re-request a review, see step 7 in the GitHub docs. Did that not work properly for you?

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/requesting-a-pull-request-review

[HonkingGoose]

I'm happy with the docs.

[zeshuaro]

It did work, but it wouldn't let me to re-request reviews from both of you. So right now I requested one of you. If I request for the other person, GitHub would remove the review request from the first person 😓

[renovate-release]

🎉 This PR is included in version 34.73.0 🎉

The release is available on:

• GitHub release
• 34.73.0

Your semantic-release bot 📦🚀

[provokateurin]

Awesome work ❤️ Thanks a lot for taking over @rarkins !

[rarkins]

No, thanks to @zeshuaro !

[provokateurin]

Ooops I didn't check the Github UI correctly