[Discussion] Should `pubspec.lock` be continued to be tracked?

[devkabiir]

I remember we removed pubspec.lock from exercises, But I see that the repo-level pubspec.lock is still being tracked. I generally prefer not tracking generated files because they introduce unnecessary noise in git diffs.

If there is use case I don't know about, please do tell. Otherwise we should stop tracking it.

Edit: Tracking pubspec.lock also distrupts the branching flow. A contributor might be working or reviewing multiple branches, due to the nature of how pubspec.lock is kept in sync with the pubspec.yaml, difference in pubspec.lock's timestamp between branches requires running pub get again, which updates the pubspec.lock timestamp. So switching branches generally requires resetting the pubspec.lock

[Stargator]

@devkabiir This is a fine discussion to have, so thanks for voicing it. The way I see it, which is just my opinion, the repo-level lock file applies to our bin scripts. This is important to consider for this conversation as they are effectively the products we are delivering to contributors.

As such, I think the lock file serves a role as defining what the most recent valid dependencies are for those scripts. I feel supported by this opinion given the official Dart website's position in this section:

If your package is an application package, you should check this file into source control. That way, everyone working on your app uses the same versions of all of the packages. Checking in the lockfile also ensures that your deployed app uses the same versions of code.

So it ensures other contributors are using the same versions of the dependencies when using the tools for producing exercises, running tests, checking formatting, and presubmit checks.

[devkabiir]

I guess everyone agrees on keeping the repo-level pubspec.lock?
We should close this issue then. This is the current behaviour.