How to define a custom file header for a Swift Package
In this post, we’ll take a look at how to define a custom file header for a Swift package, that will then be used for all new files that we create for that package.
Background
When you add a new file to a Swift package, the default package configuration will add the following file header to the file:
Compare this with the default header that we get when adding files to an Xcode project:
Regardless of what header format you prefer, the project default is at least more complete, since it includes the project name, copyright info, etc. The package header is just…broken.
With the default configuration, we have to adjust or remove the header for all new files that we add to the package. Very tedious.
How to customize the file header for an Xcode project
You can set up a custom file header for any Xcode project. This involves creating a custom IDETemplateMacros.plist file, which is thoroughly described in this post.
A project can also specify additional information, like the organization name, which will add a bottommost copyright line to the header, as you saw in the screenshot above.
Turns out that we can do the same for a Swift package, just in a slightly different way.
How to customize the file header for a Swift package
To set up a custom file header for a Swift package, just add the IDETemplateMacros.plist file to this location instead:
<Package Root>/.swiftpm/xcode/package.xcworkspace/xcshareddata
Here’s an example of a header that adds the file & package name, followed by the author & creation date, as well as an additional copyright line:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>FILEHEADER</key>
<string>
// ___FILENAME___
// ___WORKSPACENAME___
//
// Created by ___FULLUSERNAME___ on ___DATE___.
// Copyright © ___YEAR___ ___FULLUSERNAME___. All rights reserved.
//</string>
</dict>
</plist>
See this gist for a list of all the available variables that you can use in your custom header.
Make sure to check .gitignore so that the package doesn’t ignore the file, if you want it to be used all across your package.
Discussions & More
Please share any ideas, feedback or comments you may have in the Disqus section below, or by replying to this tweet or this toot.
If you found this text interesting, make sure to follow me on Twitter and Mastodon for more content like this, and to be notified when new content is published.
If you like & want to support my work, please consider sponsoring me on GitHub Sponsors.