Should pubspec_overrides.yaml update pubspec.lock

[scopendo]

Pub added support for a pubspec_overrides.yaml file to override a project's pub dependencies, which is useful for local development across a set of packages with interdependencies. Commonly, the pubspec_overrides.yaml file is added to the project's .gitignore file.

Whilst this is helpful, it strikes me as odd that the consequences of the override are reflected in the project's pubspec.lock file, which is then included in version control. Is this correct – should the locked dependencies in the repository be updated just because a team member chose to use a local override?

[sigurdm]

This is a valid point. The whole idea of pubspec_overrides.yaml was to avoid git picking up the local environment.

On the other hand pubspec.lock is the place that reflects the resolution that pub did.

Do we really need a "local_pubspec.lock"? - that sounds too complicated.

@jonasfj do you have any thoughts/ideas?

[jonasfj]

I see no good solution.

In hindsight, this is probably a good reason to not add support for pubspec_overrides.yaml.

It seems to me that options could be:

• update pubspec.lock (current behavior),
• use a pubspec_overrides.lock lock-file, or,
• don't update any lock-file when using pubspec_overrides.yaml.

Which is the right choice probably depends on your work-flow.

It's not clear to me that not having a lock-file at all, or using a different lock-file wouldn't cause confusion elsewhere.

[scopendo]

As a Flutter developer, without particular knowledge of the complexities involved, my preference would be for pubspec.lock to reflect the dependencies in pubspec.yaml including those overridden, per the most recent pub get / pub upgrade.

I would also like a pubspec_overrides.lock file that contains the overridden dependencies, which would not be included in version control.

I'd then like the build process to use the version of a dependency in pubspec_overrides.lock over pubspec.lock.

[sigurdm]

pubspec.lock to reflect the dependencies in pubspec.yaml including those overridden, per the most recent pub get / pub upgrade.

If you have a pubspec_overrides.yaml we don't resolve your pubspec.yaml also (and there might be no resolution). That means we could not create a pubspec.lock with that content.

I think implementing pubspec_overrides.lock would be really tricky to get right, leading to potential bugs in return for a rather niche feature.

[scopendo]

Again noting that I don't know the complexities, wouldn't it be a matter of "pub get/upgrade" first processing as though there were no pubspec_overrides.yaml file and then processing the overrides and putting those resolved versions into a new pubspec_overrides.lock?

I think implementing pubspec_overrides.lock would be really tricky to get right, leading to potential bugs in return for a rather niche feature.

What sort of bugs? Would they be acceptable given that this is a (very useful) convenience for local development across multiple packages?

[scopendo]

If you have a pubspec_overrides.yaml we don't resolve your pubspec.yaml also (and there might be no resolution). That means we could not create a pubspec.lock with that content.

If there were no resolution then that could be treated like any other non-existing dependency in pubspec.yaml. In this case, the dependency would only exist in pubspec_overrides.yaml until it was made resolvable. Undoubtedly some would forget and a CI build would fail due to a missing dependency but that seems acceptable to me and easily rectified.

[Akiyamka]

pubspec_overrides.lock looks reasonable for me, much better than current state. So, why not?

[Abhi011999]

Was facing this same issue, I agree with @scopendo and @Akiyamka this should be a thing

[EchoEllet]

Is this still an issue? because I still have the same question that @scopendo asked.

How about add

pubspec.lock

to .gitignore

since it can be regenerated by pub

[scopendo]

pubspec.lock is needed in version control to ensure that builds are performed with known dependency versions.