SPM: how to centralise configuration of external dependencies for many packages?

Using Swift
,
1

Hi,

I have the following scenario:

  • single repository
  • single Xcode project
  • many local SPM packages.
  • some packages reference each other
  • everything is tied together in the Xcode project and built from there into the final app.

Code that is located within the project and in the packages should use the same SPM external dependencies, referenced by URLs. (e.g. NukeUI, DIKit, Firebase etc.)

Some external dependencies can be kept local to a single package. Others can not.

What is the prefered way to centralise this kind of configuration, so I don't have to manually edit package URLs and vesion numbers in all kinds of places?

I understand there is destination.json, but that seems only applicable for compiler flags?

Is it feasible to wrap external dependencies in local proxy packages? This way, my application packages would only depend on the local proxies. Version upgrades of external dependencies would hopefully be limited to the proxy packages. Imports should stay the same.

Is this how everybody else does it?
Are there any other good ways?

Thanks!

2

You could create a package at the very bottom of your portion of the dependency graph, which references all the external dependencies with exact version requirements. Then all your packages above that point at it from a meaningless unused target (to ensure SwiftPM does not deem it unreachable and optimize it away). Your packages can then directly depend on the real dependencies with a permanent loose range requirement like "0.0.0"..<"1000.0.0", and trust that your other constraint will have forced a rational selection.

No. My rule is one package per versioning node. It sounds like your various components would properly be multiple products of a single package in my book. That way you do not need to manually track down and check higher nodes when you change something at the bottom. The block is validated as one. (And nothing outside it can break, because everything out there is pointing at a stable version anyway.)

1 Like