CMPTemplate

Introduction: This is a template repository with developer tooling already included so you can get up and running with confidence.
More: Author   ReportBugs   
Tags:

:construction:

UNDER CONSTRUCTION

:construction:

This is an in progress template repo for a Compose Multiplatform application. The README will be updated last, so if you are reading this, you are using the template at your own risk.

This is a GitHub template repository intended to kickstart development on a Compose Multiplatform application. This project comes set with a handful of tools that Adam finds important and relevant to every project. If you think something is missing, or feel strongly that a setup should be changed, please submit an Issue.

Why This Template?

The purpose of this template is to avoid any opinions on writing code. The developers should have the freedom to choose their own architecture, third party dependencies, package structure, and more.

This template is opinionated about developer tooling. Dependency management is configured, git hooks are defined, code formatting and static analysis are all there, and it even has pull request templates. The purpose of this repo is to help you get started building your next project with confidence in your code, and not telling you how to write it.

Walkthrough

If you'd like a video walk through of this template and all it has to offer, you can find that on YouTube.

// TODO: Adam to record walkthrough for this template.

Using This Template

To use this template in your own project, click the "Use this template" button at the top right of the repository. Once you do, a repository will be created for your account that you can clone and use on your device.

To setup this repository to your needs, open the setup.gradle file and tweak the renameConfig block to your needs. After that, you can run the renameTemplate gradle task to have the app module's package name and relevant strings replaced.

[!NOTE] Note that we currently do not support auto formatting after renaming template, so you will likely want to run ./gradlew formatKotlin as well to ensure all the imports are in alphabetical order after the rename flow. If you'd like to help fix this, see this issue.

In addition, it will clean up the relevant setup files and workflows that are specific to this template, it should not require any manual deletion work on your part.

What's Included

A number of third party dependencies are included in this template. They are also documented inside the documentation folder. The files inside this documentation folder are written in such a way that you can keep them in your real project, to let team members read up on why dependencies are included and how they work.

The dependencies in the template include:

  • Ktlint for formatting.
  • Detekt for code smells.
  • Git Hooks for automatically perform static analysis checks.
  • Gradle Versions Plugin for checking all dependencies for new versions.
  • GitHub Actions for running continuous integration and ensuring code quality with every PR.
  • LeakCanary for detecting memory leaks.
  • Paparazzi for snapshot testing, which can be removed via setup.gradle if necessary.
  • SQLDelight for local databases, which can be removed via setup.gradle if necessary.
  • Multiplatform Settings for local Key-Value storage, which can be removed via setup.gradle if necessary.
  • Ktor for networking, which can be removed via setup.gradle if necessary.

Danger

This template uses Danger which will perform some checks against our pull requests. You can find the list of checks in the Dangerfile. In addition, we have a GitHub Actions workflow for Danger checks.

[!IMPORTANT] In order for Danger to work properly, you'll need to give Danger permission to comment on your repository. You can do so by navigating to Repository Settings -> Actions -> General, scroll down to Workflow Permissionsand set the permissions to read and write.

Templates

There are also templates within this template. This repo comes shipped with a Pull Request Template that will help you and your team write organized and detailed pull request descriptions.

Dependency Setup

You may notice that dependencies are set up in a very specific way. Each of the tools has its own Gradle file in the buildscripts folder. This is by design so that if you chose to have a multi module project, these dependencies can easily be shared between them. This is already configured inside our root build.gradle.kts file, by applying to each sub project:

subprojects {
    apply from: "../buildscripts/detekt.gradle"
    apply from: "../buildscripts/versionsplugin.gradle"
}

In addition, all of the app module dependencies are defined using a gradle version catalog, found in this toml file.

Apps
About Me
GitHub: Trinea
Facebook: Dev Tools