If you’re short on space and want to clean up your local Swift Package Manger repos, you can easily remove build products by issuing:
UsefulModifiers% swift package clean UsefulModifiers%
This is particularly helpful for people, like me, who develop in Xcode where it’s easy to clean your product’s build folder but forget that there’s also mess with SPM. GrandPerspective or any of the other file space visualizers is great for seeing where your clutter builds.
Also, while I’m chatting about SPM builds, I find that a lot of people forget that
swift package init offers separate initializers for
executable. Just pass
--type library for example. I’m doing a lot of library and executable work these days so it helps to have that set up for you.
I’m not crazy about everything that SwiftPM sets up, so I’m finding myself more often creating my manifests by hand.
I use a global git ignore file located in my home directory, so one of my first steps is to always dump the
.gitignore that SwiftPM creates for me.
[core] editor = vi excludesfile = ~/.gitignore_global
I populate my git ignore file with gitignore.io. It’s a great resource for building savvy collections. Mine includes, among others, ignore groups for Xcode, Swift, Objective-C, macOS, Emacs, CocoaPods, Carthage, SwiftPM, and more.
I automatically add CHANGELOG.md and LICENSE.txt files, which I think SwiftPM should consider doing as well.
When developing in Xcode native, make sure you are using the right source and test folders. Notice that the preceding screenshot has both
UsefulModifiers. I’m currently leaning towards reconfiguring my Xcode project to use the default SwiftPM folders but I’ve also gone the other direction. For example, you can set your target
path: to specify where to look for your source material to compile:
targets: [ .target( name: "UsefulModifiers", dependencies: [.product(name: "ArgumentParser", package: "swift-argument-parser")], path: "UsefulModifiers/" ), ],
Always confirm that the default Swift version in the comment at the top of the file is the one you want to work with. I recently spent time updating my Swifts back to 5.1 so they’d run on Mojave systems:
Of course, if you’re building new libraries of modifiers and views for SwiftUI, make sure you’re using the latest tools.
Speaking of “latest”, it’s important to think about version drift when it comes to your dependencies. I’ve been leaning towards always freezing my dependencies for any distribution to ensure that my code will keep compiling until I’m ready to move those dependencies forward.
Setting an exact dependency avoids the unnecessary pain of your dependency updating (SAP at the moment is 0.2.0) and your code dying as a result:
dependencies: [ .package( url:"https://github.com/apple/swift-argument-parser", .exact("0.1.0")), ],
At the same time, I think one of the most exciting things this week for me was Xcode’s automatic search and support of views and modifiers. Building a smart package that can be added to normal app development and updated over time, and whose bounty automatically appears in the resource library is just marvelous.
I thought I’d share some SwiftPM thoughts as I put together exactly that. Are you building your own View and Modifer libraries? Anything public? I’m curious as to what everyone else is working on!
I think you allude to this, but I wish package init had a binary-with-library template. I almost always want to stuff everything except possibly command line handling in a library even if I’m working on a CLI tool, and I don’t think I’m alone in this. Now it’s always a few extra hoops.