pub get (flutter) changes pubspec.lock EOL to LF even when on windows

Created on 7 May 2020  路  8Comments  路  Source: dart-lang/pub

Environment

  • Flutter Pub version: Pub 2.8.1
  • OS: Windows 10 1909 build 18363.418

Problem

Pub get is not aware of platform specific EOL conventions which makes git go crazy and report changes to pubspec.lock even when the packages are still the same.

To reproduce:

  1. Create a new flutter project (flutter create buggy)
  2. Initialize a git repo in the project folder (cd ./buggy & git init)
  3. Ensure core.autocrlf is set to true on git (git config core.autocrlf true)
  4. Add and commit all files (git add . & git commit -m "Initial commit")
  5. Upload to github and clone the repo to a new folder
  6. Run pub get

Then if you do git status a change to pubspec.lock is reported even if the content is the same (except the EOLs)

Expected behavior

pub get should use CRLF as a EOL character when on windows.

Actual behavior

pub get writes pubspec.lock file with LF characters.

All 8 comments

Thanks for reporting.

You can configure git to use LF for specific files (for example pubspec.lock).

See eg. https://help.github.com/en/github/using-git/configuring-git-to-handle-line-endings

Most windows tools today work fine with LF endings. I am not sure we are going to change this.
@jonasfj WDYT?

We could mention the .gitattribute fix on:
https://dart.dev/tools/pub/troubleshoot

Hmm, but if this is a problem for many users we should come up with a solution. I don't actually know if windows users generally use CRLF or just LF. We should probably find out what most Windows users do, if they have git config core.autocrlf enabled or not.

But a possible solution would be read the existing pubspec.lock file and if it is valid YAML and uses CRLF then we write the new pubspec.lock using CRLF.

I'm not sure why git think there is a change, if it tries to make a commit, then after converting back to LF there should be no changes.

I wonder what other package managers do?

https://github.com/npm/npm/issues/17161 npm had the same issue.
They did detection of current newlines: https://github.com/npm/npm/pull/18943. (Well actually https://github.com/npm/npm/pull/19904 but it seems they would have preferred the other).

Detecting newline-mode is probably rather harmless... As a linux user I can't imagine having CRLF anywhere. But if somehow I got CRLF in my repository, there is supposedly no harm in preserving it when updating pubspec.lock.

Another possible fix is to do a deep-compare of YAML dictionary from pubspec.lock with the dictionary we want to write. And if there is no change we don't overwrite the file and instead just touch it (to update timestamps).

I guess we don't want to preserve newline style in .packages and .dart_tools/package_config?

These are not supposed to be checked in, and should thus not give problems with source control.

I agree, that for .packages and .dart_tool/package_config.json we don't do anything they should never be checked into git anyway.s, or copied between computers..

We could use the platforms preferred newline format if we wanted to.

We could use the platforms preferred newline format if we wanted to.

We could... But besides that being more complicated, I am not sure that \r\n is always the preferred line-ending on windows. I think that depends a lot on the tools you are using.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jayoung-lee picture jayoung-lee  路  38Comments

samueladekunle picture samueladekunle  路  25Comments

Andersmholmgren picture Andersmholmgren  路  45Comments

pq picture pq  路  24Comments

sinadarvi picture sinadarvi  路  24Comments