Dart frequently updates pubspec.lock. When multiple developers are fetching and pushing changes to a shared repo, pubspec.lock is a common source of merge conflicts. It also pollutes the PR, making it harder to review.
Reproduction steps:
Run dart pub get after any project dependency has changed.
Add and commit changes with git.
Open a PR on the upstream repo.
Expected result:
The PR should omit any local changes to pubspec.lock. The static_shock repo should not include pubspec.lock files at all.
Actual result:
The PR includes pubspec.lock (potentially more than one, since static_shock includes multiple packages).
Resolving ambiguities
This PR could be resolved by adding pubspec.lock to .gitignore. In fact, this is the recommendation for libraries in the Dart documentation.
Committing pubspec.lock to source control may perhaps be useful at times for an application where all of the developers need to ensure that they are building exactly the same binary. However, for shared libraries it is better for everyone to create their pubspec.lock files locally.
I'm not suggesting we add pubspec.lock to the .gitignore of generated projects, only to the static_shock repo itself.
I am suggesting we specifically add pubspec.lock to the .gitignore at the top level. Adding it to sub-packages is also fine, but would be unnecessary if it were already included at the top level. The reason for this is that it's easy to forget when adding another package. For example, packages/static_shock includes it while the other packages omit it. Apparently that was just an oversight.
Dart frequently updates
pubspec.lock. When multiple developers are fetching and pushing changes to a shared repo,pubspec.lockis a common source of merge conflicts. It also pollutes the PR, making it harder to review.Reproduction steps:
dart pub getafter any project dependency has changed.git.Expected result:
The PR should omit any local changes to
pubspec.lock. Thestatic_shockrepo should not includepubspec.lockfiles at all.Actual result:
The PR includes
pubspec.lock(potentially more than one, sincestatic_shockincludes multiple packages).Resolving ambiguities
This PR could be resolved by adding
pubspec.lockto.gitignore. In fact, this is the recommendation for libraries in the Dart documentation.Committing
pubspec.lockto source control may perhaps be useful at times for an application where all of the developers need to ensure that they are building exactly the same binary. However, for shared libraries it is better for everyone to create theirpubspec.lockfiles locally.I'm not suggesting we add
pubspec.lockto the.gitignoreof generated projects, only to thestatic_shockrepo itself.I am suggesting we specifically add
pubspec.lockto the.gitignoreat the top level. Adding it to sub-packages is also fine, but would be unnecessary if it were already included at the top level. The reason for this is that it's easy to forget when adding another package. For example,packages/static_shockincludes it while the other packages omit it. Apparently that was just an oversight.