# skpm: scaffolding, building and publishing Sketch plugins from one command line

> skpm is the Sketch Plugin Manager, a command line utility that generates a plugin project from a template, builds it with webpack, tails the plugin log and publishes a release to GitHub plus the plugin directory. The workflow it describes is still clear, but the tooling it was written against dates from 2017.

**skpm/skpm** — 💎📦  A utility to build and publish Sketch plugins

- Repository: https://github.com/skpm/skpm
- Stars: 960 · Forks: 78
- Language: JavaScript
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/skpm-skpm

## What skpm automates for a Sketch plugin author

skpm is the Sketch Plugin Manager, a utility to create, build and publish Sketch plugins. The problem it solves is mundane and real: a Sketch plugin is a JavaScript bundle with manifest files, a build step, a log file somewhere on disk, and a release process that involves GitHub and a shared registry. Done by hand for every plugin, those steps get repeated inconsistently.

skpm covers four of them. It creates a new plugin project from a template, it builds and watches the project, it shows the plugin output log, and it publishes a new version.

The audience is Sketch plugin developers who want a project skeleton and a repeatable release procedure rather than a plugin framework. Note what it is not: it does not provide the APIs a plugin calls into Sketch, it does not bundle UI components, and it does not define how your plugin code should be structured. The templates exist precisely to be opinionated about tooling while staying out of the way of your own code.

That distinction is stated in the documentation's note on templates. Official templates provide opinionated development tooling setups so users can get started with actual plugin code as fast as possible, and they are un-opinionated in terms of how you structure your plugin code and which libraries you use in addition to skpm.

## The Node.js floor and the macOS command line tools requirement

Installation is one command, but the prerequisites are stated firmly and both of them are easy to miss:

```bash
npm install -g skpm
```

The documentation marks this as important. Node.js is required, with V6.x given as the minimum requirement, and the macOS command line tools must also be installed.

The Node.js floor is generous for a project of this age. The command line tools requirement is more specific to the platform: the macOS developer tools are what provide git and the compilers that a webpack-based JavaScript build needs, and their absence produces errors that look nothing like a missing prerequisite.

The global install is deliberate rather than accidental. skpm is used to scaffold projects in many directories, and it is also used inside a project folder for the log and publish commands, so it is a machine-level tool in the same way a version control client is.

One structural note from the repository layout: the root package.json is marked private and holds only the development tooling for the project itself, with babel-cli, eslint, prettier and lint-staged as devDependencies and scripts for formatting and linting. The packages directory holds the actual code, and the template directory holds the scaffolding used by the create command.

## skpm create and the template folder convention

Creating a plugin pulls a template, asks a few questions and writes a project:

```bash
skpm create my-plugin
```

The template comes from the repository itself, and the project is generated at ./my-plugin/. The command accepts a set of options that control naming, location and what gets initialised:

```bash
skpm create <plugin-name>

--name        The plugin display name.
--cwd         A directory to use instead of $PWD.
--force       Force option to create the directory for the new app. [boolean] [default: false]
--template    The repository hosting the template to start from.    [string]  [default: skpm/skpm]
--git         Initialize version control using git.                 [boolean] [default: true]
--install     Installs dependencies.                                [boolean] [default: true]
```

The defaults are sensible for a quick start. Version control is initialised and dependencies are installed unless you say otherwise, and the template repository defaults to skpm/skpm, described as the simplest possible plugin setup.

Beyond the default there are four official alternatives. skpm/with-prettier adds linting with ESLint and formatting with Prettier. skpm/with-datasupplier is for DataSupplier plugins. skpm/with-webview targets plugins that display rich UI in a WebView. skpm/with-actions targets plugins built on the Actions API.

The open-ended part is the custom template. Any GitHub repository with a template folder can be used, passed as a username and repository pair:

```bash
skpm create <project-name> --template=<username>/<repository>
```

That convention is why the folder name matters. A team with its own build setup can keep it in a template folder inside an internal repository, and every new plugin starts from it.

## Building, watching and running the plugin inside the project folder

Once the project exists, the day-to-day commands are npm scripts run inside the project directory.

A production build is:

```bash
npm run build
```

To rebuild as files change:

```bash
npm run watch
```

And to have the plugin run every time it is built:

```bash
npm run start
```

That third script is the one that changes the feedback loop. Without it, a build produces an artefact and you reload Sketch yourself. With it, each rebuild reloads the plugin, so a change to a function can be seen in a running Sketch in seconds.

The build itself is webpack based, and the topic tags for the project include webpack along with manager, plugin, registry, sketch and sketch-plugin.

What the build produces matters for the release step later. The packaging step zips the folder specified in the main field of package.json, which means the main field in a plugin manifest defines what gets shipped, not just what gets loaded. Getting that wrong produces a release that installs but does not contain the code.

## skpm log tails the file Sketch writes for you

Plugin authors need to see console.log output, and Sketch does not print it to a terminal. There are several ways to see it, and the documentation lists three: use the sketch-dev-tools project, open Console.app and look for the Sketch logs, or read the log file directly at ~/Library/Logs/com.bohemiancoding.sketch3/Plugin Output.log.

skpm wraps the third option. The command is short:

```bash
skpm log
```

It exposes the tail behaviour it inherits, with a follow flag and a line count:

```bash
skpm log

  -f, -F        The `-f` option causes tail to not stop when end of file is
                reached, but rather to wait for additional data to be appended
                to the input.                       [boolean] [default: "false"]
  --number, -n  Shows `number` lines of the logs.                       [number]
```

So the flags map onto familiar tail semantics. -f follows the file as it grows, and --number limits how much history is shown, which matters when a plugin has been running for a while and you only want the last few lines.

The hard-coded path is the macOS convention, and it is worth noting that the path names the sketch3 application directory, so a Sketch version that changes its bundle identifier or log location would break this shortcut.

## skpm publish and the exact order of the release steps

Publishing accepts either an explicit version or a semver keyword:

```bash
skpm publish <new-version> | major | minor | patch | premajor | preminor | prepatch | prerelease

  --repo-url          Specify the repository URL (default to the one specified
                      in package.json).                                 [string]
  --skip-release      Do not create a release on GitHub.com.           [boolean]
  --open-release, -o  Open the newly created release on GitHub.com.    [boolean]
  --skip-registry     Do not publish to the plugins registry if not already
                      present.                                         [boolean]
  --download-url      Specify the new version's download URL (default to the
                      asset of the release created on GitHub.com).      [string]
```

The documented execution order, without options, is a specific script rather than a general description. The preversion script runs, the version field in package.json is bumped as requested, the version script runs, the change is committed and tagged, and the postversion script runs. Then the prepublish or build script runs, the folder specified in the main field is zipped, a draft release is created on GitHub, the zip is uploaded to GitHub, the release is published, and the zip is removed. Finally the plugin directory repository is checked to see whether the plugin is already listed, and if not, a pull request is opened to add it.

Two things follow from that order. The npm lifecycle hooks are honoured, so a team can hook their own checks into preversion or prepublish. And the final step writes to a shared registry repository that you do not control, which is why --skip-registry exists.

The --download-url option overrides the assumption that the download URL is the GitHub release asset, which is what you need when the artefact is hosted elsewhere.

## A release history that stops in 2017 and a Babel 6 era build

The maintenance picture is the part to weigh carefully. The repository is not archived and the last push was on 2026-04-23, so there has been recent activity on the repository itself. The published releases, however, stop much earlier: v0.10.3 on 2017-07-24, v0.10.2 on 2017-07-17 and v0.10.1 on 2017-07-09. Three patch releases in a single week in July 2017 is the visible release pattern.

The build tooling in the repository matches that era. The devDependencies are babel-cli and babel-core at 6.x, babel-preset-env, eslint at 5.x with the airbnb-base and prettier configurations, prettier at 1.x, and lint-staged at 8. The lint-staged configuration runs prettier and eslint on staged JavaScript and prettier on staged Markdown, and a pre-commit hook is installed. The test script is eslint with the gitignore passed as an ignore path, so linting is the test suite rather than a unit test run.

The licence is MIT, which is permissive and requires only that the notice travels with copies and substantial portions of the code.

For a team starting a Sketch plugin today, the honest reading is that skpm remains a clear description of a workable workflow, while the pinned toolchain in the repository is old enough that you may find yourself bumping dependencies during your first install. Nothing in the documentation addresses Node.js versions beyond the V6 minimum, and the registry publishing path depends on GitHub pull request practices that have changed since 2017.

## Conclusion

Adopt skpm if you are writing Sketch plugins now and want the scaffold, build, log and publish steps defined once instead of by hand, especially if you are starting from the official templates. Skip it if you need current Sketch tooling guarantees, because the published releases stop at v0.10.3 from 2017 and the repository build depends on Babel 6, ESLint 5 and Prettier 1. Before adopting, check that your Node.js version satisfies the stated V6 minimum, confirm the command line tools are installed on macOS, and read the plugin directory pull request step in the publish sequence, since publishing affects a shared registry.

## FAQ

### How do I install skpm for Sketch plugin development?

Install it globally with npm install -g skpm. The documentation states that Node.js V6.x or newer is a minimum requirement and that the macOS command line tools must also be installed.

### How do I create a new Sketch plugin with skpm?

Run skpm create my-plugin, which pulls the template, prompts for some information and generates the project at ./my-plugin/. Options include --name, --cwd, --force, --template, --git and --install, and the default template repository is skpm/skpm.

### Can I use my own template with skpm create?

Yes. Any GitHub repository with a template folder can be used, by passing --template=<username>/<repository> to skpm create. The official alternatives include skpm/with-prettier, skpm/with-datasupplier, skpm/with-webview and skpm/with-actions.

### How do I see the log output of a Sketch plugin?

Run skpm log inside the project folder, which reads the Sketch plugin log file. The -f or -F flag makes it follow the file as new lines are appended, and --number limits how many lines are shown.

### What does skpm publish do when I release a new plugin version?

It runs the npm lifecycle scripts, bumps the version in package.json, commits and tags, builds, zips the folder named in the main field, creates and publishes a GitHub release with the zip, removes the zip, and opens a pull request to the sketchplugins/plugin-directory registry if the plugin is not listed there.

## Sources

- [Issues](https://github.com/skpm/skpm/issues)
- [License: MIT](https://github.com/skpm/skpm/blob/master/LICENSE)
- [README](https://github.com/skpm/skpm/blob/master/README.md)
- [Releases](https://github.com/skpm/skpm/releases)
- [skpm/skpm on GitHub](https://github.com/skpm/skpm)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/skpm-skpm