Using Xcode 16 beta, I've found that Package.resolved seems to have moved. Where it would previously be in the root of my package directory, I've found the new tooling putting it in .swiftpm/configuration/. Is this an intentional change?
I've tried multiple times, but I cannot find any mention of this change in Swift PM release notes, Swift PM commit notes, the Swift PM change log, Swift PM pull requests or issues, Swift forum discussions, or even Xcode beta release notes.
I don't mind if the default location has moved, and if the new tools simply picked a new default location when creating a new package, I wouldn't think much of it. However, even within my existing packages, the new tools seem to be creating a brand new Package.resolved in the new location without moving or removing the file from the old location. Now I have two Package.resolved files, which may be different, and I don't know what's going on.
I feel like I must have missed some note on this somewhere, as this change is immediately very visible (even if it's not the most important). Can anyone point me to any documentation, commit notes, etc.? Will this behavior be the new default?
Xcode’s SPM integration isn’t beholden to any particular process. If you mean from swift directly, that would be surprising. The resolved file should neither be hidden nor anything but a sibling of the Package file.
I believe this to be the behavior even prior to Xcode 16. Package.resolved only applies when you are building the package directly, and is ignored in all other cases, including when building a package that depends on your package. Building in Xcode (I'm guessing you are using a workspace or something like that) is equivalent to building a package that depends on your package, only instead of a package it is an Xcode project. So your root-of-directory Package.resolved is ignored, and Xcode happens to use a similar mechanism to pin dependency versions, placing the result in .swiftpm.
In the past, I have worked around this by symlinking Xcode's Package.resolved to the root Package.resolved.
I do not use workspaces. These packages were created as standalone libraries, not part of Xcode projects. They were not created in Xcode.
Over the last few months, I've built several packages using the 5.10 tools. I always create a new directory, initialize a package with swift package init --type library, and then open the Package.swift file (which opens the package for editing in Xcode).
Later, I will add package dependencies. When building using Xcode 15, a Package.resolved file would be created for me, in the root directory of my package, next to Package.swift.
I know this has been the case in the past, because I've seen other threads in this forum with folks commenting that having Package.resolved next to Package.swift is inconvenient, because resolved autocompletes before swift in the terminal and it's rarely the file you actually want.
However, after switching to Xcode 16 beta (xcode-select -s /Applications/Xcode-beta.app), this no longer seems to be the case. Again, I don't really mind, I just wish I could find some documentation. Also it would be nice if SPM didn't seem to pretend my existing Package.resolved files weren't already there.
With regard to Xcode, I think its influence here is limited. I will admit the Swift toolchains I'm using are the ones bundled with Xcode. If there is something different about those, then that could be it. However both my 5.10 and 6 beta tools are from Xcode, so even in that case it would be a change.
I stand corrected. It seems like this is, somehow, an Xcode issue.
Although I used swift package init to create packages, they would obviously start with no dependencies. Using Xcode as my editor, I would then add dependencies at some point. Xcode would dutifully resolve and load the dependencies. However, it's the one putting the Package.resolved file in the wrong place.
If I get rid of the existing Package.resolved files and use swift package resolve, the Package.resolved file does indeed get placed in its usual spot, the root directory of the package.