track pubspec.lock files

[andrewkolos]

Description

While working on #364 I observed a lint failure in CI but not locally:

Run flutter analyze --fatal-infos
Resolving dependencies...
Downloading packages...
  characters 1.4.0 (1.4.1 available)
  material_color_utilities 0.11.1 (0.13.0 available)
Got dependencies!
2 packages have newer versions incompatible with dependency constraints.
Try `flutter pub outdated` for more information.
Analyzing travel_app...                                         

   info • 'webProvider' is deprecated and shouldn't be used. Use providerWeb instead. This parameter will be removed in a future major release • lib/main.dart:22:5 • deprecated_member_use

1 issue found. (ran in 12.8s)

(I can't link the job because GitHub doesn't follow the link correctly)

IIRC this was happening because my PR was trying to revert back to webProvider because providerWeb didn't exist for me. To try to fix this, I tried to revert this revert, going back to the providerWeb parameter, but it didn't exist for me, so I figured my locally installed version of package:firebase_app_check must be stale.

Indeed, it looks like this deprecation was just recently introduced: firebase/flutterfire@3c63826#diff-4de6eedeaecca576ac4d131446b8549c1dcebfdcaba87384c28adcd109583da7R73-R76

This PR fixes the top level .gitignore to stop ignoring **/pubspec.lock to make sure local dev environments and CI are using the same versions of dependencies.

Warning

This has the downside of CI builds not using the latest and greatest versions of dependencies. However, I don't think we are currently publishing from CI, so this isn't an issue right now. Regardless, I recommend running flutter pub upgrade when publishing new versions of packages from this repo and checking in those changes. Another thing we could do is use a bot to periodically upgrade packages for us, which is done in the framework repo: flutter/flutter#176764

Pre-launch Checklist

• I read the Flutter Style Guide recently, and have followed its advice.
• I signed the CLA.
• I read the Contributors Guide.
• I have added sample code updates to the changelog.
• I updated/added relevant documentation (doc comments with ///).

If you need help, consider asking for advice on the #hackers-devrel channel on Discord.

[jacobsimionato]

I read that we should version control this file for application packages, but not for libraries - https://dart.dev/tools/pub/private-files#pubspec-lock

I'm kind of new to pub because I spent my life in google3! Does this make sense? If so, should we just .gitignore the package ones?

[gspencergoog]

I think we should follow the guidance and only commit the app pubspec.lock files.

[andrewkolos]

I read that we should version control this file for application packages, but not for libraries - https://dart.dev/tools/pub/private-files#pubspec-lock

I'm kind of new to pub because I spent my life in google3! Does this make sense? If so, should we just .gitignore the package ones?

From that link:

For regular packages, don't commit the pubspec.lock file. Regenerating the pubspec.lock file lets you test your package against the latest compatible versions of its dependencies.

Interesting! I did consider this type of point from the perspective publishing but not for testing purposes (which we do have CI for today). It seems like the Dart-idiomatic way is to prioritize the library consumer over the contributor here. I wonder if other ecosystems tend to do this differently. Regardless, this isn't worth any more thought right now in my opinion, so I'm closing this.

[jacobsimionato]

Hey no worries! I think most of your change is good though, @andrewkolos , because we actually have several apps in this repo, e.g. the demo apps. So please do feel free to just check in the app pubspec.lock files!