Note: Remove this section before publishing your package.

This repository contains a template directory structure for SPM Library Packages.

1. Clone this repository

   git clone https://github.com/ladislas/SwiftPM-Package-Template path/to/PackageName

2. cd to the cloned repository

   cd path/to/PackageName

3. Delete .git

   rm -rf .git

4. Generate your own package with swift or ice

   swift package init # or ice init

5. Reinit git and git flow

   git init # and optionally git flow init

6. Create your repo on Github and add remote

   git remote add origin https://github.com/{user_name}/MyPackage

You're now set up to start developing! 🎉

This README.md provides you with a the basic information that should present your package's README.md.

I've added comments and marks using {change_me}. Running the following command in your terminal will help you locate & change them:

ag "{change_me}" # or ack "{change_me}" # or grep -rnw '.' -e '{change_me}'

The Examples folder is here if you want to provide examples showing how to use your library. Even though documentation and test suites can be helpful resources, it's always a good thing to showcase your library in a "real life" example.

If you want to create an example, just do the following:

# cd to Examples cd Examples # create example directory & cd into it mkdir MyFirstExample && cd $_ # init example ice init -e # or  swift package init --type executable # I usually remove the test folder to only keep sources rm -rf ./Tests

Then, for your example to use your library from the local sources and not from a remote repository, add this to your Package.swift (change the PackageName):

dependencies: [ .package(path: "../../../PackageName") ],

With this, you can write your examples as your write your library. I really like to be able to immediately use the code. It helps me get a better feeling and can also help with refactoring.

The docs folder is used for documentation. If you use Jazzy, you can just run jazzy at the root of the project and it will put all documentation to docs.

You can then publish it directly on Github. Here are the instructions.

If you need continuous integration and code coverage, we got you covered!

I personally use Travis CI and SonarCloud. The latter provides you with code coverage and static analysis. And it's super easy to make it works.

To simplify the process & scripting, we are using IBM's Package-Builder and providing you with a .travis.yml file and a sonar-project.properties file.

Steps are:

1. Activate repo on Travis CI
2. Create new project on SonarCloud and generate token
3. Add token to Tracis CI as SONAR_LOGIN_TOKEN
4. Enjoy

Detailed instructions on how to use both are available here:

Package-Builder SonarCloud Instructions

We've also added a MyProject.podspec file if you want to publish your library to Cocoapods.

Check Podspec Syntax Reference and Marking a CocoaPod for more information.

This project is under Apache 2.0, but feel free to change the License of your own project.

A lot of badges are present at the top of the README.md. Feel free to keep them or remove them.

If you keep them, you need to change the link they point to with your owns.

Describe what your project does.

Describe the main features.

• - it does this
• - and also this
• - but not that

With SPM, add the following to the dependencies of your Package.swift

.package(url: "https://github.com/{change_me}/{change_me}}", from: "1.0.0")

You want to add pod 'MyPackage', '~> 1.0' similar to the following to your Podfile:

target 'MyApp' do pod 'MyPackage', '~> 1.0' end

Then run a pod install inside your terminal.

Just copy the Sources files into your project.

Describe a simple usage

See docs, Examples & Tests for more information.

import MyPackage let myObj = MyClass() ...

Made with ❤️ by:

• {change_me} - ladislas

Explain how people can contribute to your project

We welcome contributions, and request you follow these guidelines.

Please raise any bug reports on the issue tracker. Be sure to search the list to see if your issue has already been raised.

A good bug report is one that make it easy for us to understand what you were trying to do and what went wrong. Provide as much context as possible so we can try to recreate the issue.

Apache 2.0 @ Ladislas de Toldi