Application packages should commit their pubspec.lock to git [1].

Non-application-packages should git-ignore their pubspec.lock files.

However, if I have a pub workspace containing both applications and non-applications, I only have a single pubspec.lock at the workspace level. Should i commit that lock file to git or not? I think the answer is yes, because the workspace lock is inconsequential for packages when they are used as dependencies.

(Alternatively, we could consider copying the pubspec.lock next to all pubspec.yamls it applies to. Then the copies for the application-packages can be committed and the copies for the non-application packages can be git ignored. However, that would be weird because when resolving the workspace you'd have to check all the locks.

One question is whether a pubspec.yaml that has resolution: workspace should be able to stand on itself. It should be, and its dependencies should be correct if it doesn't have publish_to: none. Because someone could depend on it or dart pub global activate it. If the pubspec.yaml does stand on itself, it should be accompanied by a pubspec.lock. This would argue for copying it next to all pubspecs in the workspace! And it would enable dart pub global activate --source=git --git--path=<...> and dart pub global activate <package_name> to do the right thing. (Context: We're exploring using pubspec.lock in d p g a to lock the transitive dependencies.))

Edit: We can't actually verbatim copy the workspace pubspec.lock because it contains none of the packages in the workspace itself. We'd need to add the other packages in the workspace (the transitive deps within the workspace).

[1] https://dart.dev/tools/pub/glossary#application-package