Package.resolved should go in the .gitignore

it is still extremely difficult to develop a project and its dependencies in tandem

You're not wrong, there. What I've wound up doing is having lines in my main Package.swift that list the dependencies on my local system, alongside the same dependency listed with its git URL, and I comment out the repo dependency until I'm actually ready to release that library. It's manual, it's ugly, and it sometimes leads to successive commits with only whitespace changes just to get the build chain to recompile stuff, but it works.

2 Likes

As an aside (and perhaps this should be a separate post), I do wish that Package.resolved was called something else.

If it's really intended as a machine-readable file, it would be better off with a hidden-by-default name such as .Package.resolved.

If it must stay visible, it would be a major quality-of-life improvement if it didn't come before Package.swift when sorted alphabetically! Having both causes filename completion in shells to have to ask which you want, and/or pick a default - and the first choice will be .resolved, which is invariably the one you didn't want.

7 Likes

The Package.resolved is a main source of conflicts for us in our main Xcode project, on a semi-large team since we maintain a few in-house packages which are versioned multiple times a day.

All our dependencies are always pinned to exact versions, is there an issue adding the package.resolved to the gitignore if only to remove the need to resolve conflicts on the file?

Is it still possible with exact versions that having the file gitignored could result in team members working against different versions of the packages?

It depends on if you can guarantee the version will not be reused perhaps you are able to do exact pinning on the exact version of the module as a substitute of including the packages resolved file. I think it is one of those things where there is no perfect frictionless path but just alternatives each with their own pros and cons.

if you commit the file instead of gitignore you avoid a lot of "it builds on my machine" discussions. In many use cases you want the build machine to resolve with exact same swift code as your machine. You can always put your own gitignore rule, it is not that hard.

2 Likes

If you are planning to use Xclod cloud you must include it in git.

Apple doc say

If you use Swift package dependencies in your project, make sure to include the Package.resolved file in your Git repository and commit any changes to it

source: Apple Developer Documentation

1 Like