Theme Kit pushed and watched Shopify themes, and Shopify deprecated it

The first thing the README says is that you should not use this

The README opens with a warning block, and it is the most important content in the file.

Theme Kit has been deprecated. Theme developers should use Shopify CLI for Shopify theme development, as parts of Theme Kit will become unsupported and may stop working soon.

That wording is deliberately hedged, and it is the hedge that matters. It is not saying the tool is broken today, and it is not saying the code has been deleted. It is saying that some parts of it will stop being supported, at a time the project has not specified, and that you should not plan new work on it.

The rest of the README describes Theme Kit as a cross-platform command line tool that you can use to build Shopify themes, a Shopify Theme Manipulation CLI, with the documentation at shopify.dev/tools/theme-kit. The features list covers four things: using workflow tools like Git to work with a team of theme developers, uploading themes to multiple environments, watching for local changes and uploading them automatically to Shopify, and working on Linux, macOS and Windows.

The release history is consistent with a tool in its final phase. v1.3.1 came in December 2022, v1.3.2 in March 2024, and v1.3.3 in October 2025, with the last push on 2026-09-25. So it is still being touched, which is presumably the work of keeping it running rather than growing it, and the version number has not moved in a year.

The project is MIT licensed, written in Go, and the repository is not archived, so the code is readable and the tool still runs.

The watcher is the feature that made Theme Kit useful

Of the four features, three are about moving a theme around and one is about the development loop, and the fourth is the one that changed how people worked.

Uploading themes to multiple environments is what Theme Kit is named for. A Shopify theme lives in several places, a development theme, a staging one, and the live one, and a tool that can address them by name from a config file removes a lot of careful manual work and the risk of pushing to the wrong one.

The watcher is the other half. Watch for local changes and upload them automatically to Shopify means you edit a Liquid template, save, and the change is on the development theme before you finish typing the next line. That loop is what makes the difference between a theme workflow and a deployment script.

The implementation is visible in the dependency list. radovskyb/watcher is the filesystem watcher library, and the presence of the AWS SDK, aws-sdk-go, is what handles the upload to the Shopify endpoints. So the tool is watching a local directory and pushing files over the network to a hosted platform, and the two halves of that are exactly the two dependencies that stand out.

The remaining feature, using workflow tools like Git to work with a team, is really a statement about how the tool is meant to fit. Theme Kit is not a version control system and does not try to be one. It is the piece that moves a checked-out working tree to the platform, which is why the workflow tool in the list is Git and why the configuration reference documents the environments you can push to.

The Node wrapper is how you pin the binary

There is one install route in the README that is a code block, and it is the one that matters for automation.

If you want to integrate Theme Kit into your build process, you can run the following npm command to install the Node wrapper around Theme Kit:

$ npm install @shopify/themekit

The wrapper is a separate project, node-themekit, which downloads and runs the Theme Kit binary. The reason it exists is the one every binary distribution has to answer: if your CI runs the tool, the version has to be pinned to something reproducible, and an npm dependency in a lockfile does that better than a download script on each machine.

The other install routes are per operating system, with links to the getting started page for Linux, macOS and Windows. Those are the interactive installs for a developer working on one machine, and the README does not reproduce the commands, so the platform-specific detail lives in the documentation rather than here.

There is a MANUAL_INSTALL.md at the top of the repository, which suggests the manual path is still maintained, and a choco/ directory, which is the Chocolatey packaging for Windows, so there is a package manager route for that platform as well.

The distinction between the interactive install and the Node wrapper is worth holding onto. If you are a developer with one machine, the platform install is fine and simpler. If Theme Kit runs in CI, the wrapper is the only way to know which version ran.

The dependency set shows the age of the code

The go.mod gives a clear picture of a Go project that was assembled in the 2016 to 2018 period and has been patched since.

The versions are old in a way that is worth noting. aws-sdk-go is at 1.34.0, which is the last release of the v1 SDK before the v2 line. cobra and pflag are on their pre-1.0 tags, viper is not present but yaml.v1 is used for configuration, testify is at 1.5.1, and golang.org/x/sync is at v0.1.0. The Go language version in the module is 1.22.1, which is current, so the toolchain line was updated even though the libraries were not.

The library choices still map to the features. godotenv reads a .env file, which is how the store credentials and password are supplied. shibukawa/configdir locates the per-platform configuration directory, and go-glob expands patterns, which is how a configuration value can point at several theme directories. caarlos0/env reads environment variables into structs, and fatih/color and mattn/go-colorable handle terminal output. hashicorp/go-version compares version strings, which is what the update check needs, and inconshreveable/go-update is the self-update mechanism.

The progress bar, mpb, and the ewma indirect dependency are for the upload progress display, and the fact that mpb depends on ewma is a small reminder of how much of the dependency tree is transitive in a project of this vintage.

The build system reflects the same history. The Makefile's all target builds for windows 386 and amd64, darwin amd64, linux 386 and amd64, and freebsd 386 and amd64, zipping each into build/release, and the binary is called theme. golint is the linter, and the test target runs go test with the race detector, coverage and atomic cover mode. The presence of a 386 build target is a clear marker of when this was written, since 32-bit Windows is not a target anyone ships to now.

Where Theme Kit is the wrong choice

The first limit is the one the project states: do not start new work on it. The warning says parts of Theme Kit will become unsupported and may stop working soon, and a theme tool that talks to the Shopify platform is exactly the kind of thing that breaks when the platform's API changes underneath it. The fact that the last push is more recent than the last release suggests maintenance, but the direction of travel is stated and it is one way.

The second is the age of the dependencies, which matters more here than it would for a typical Go tool. The AWS SDK v1 that Theme Kit uses is no longer the current line, and the whole point of the tool is to make authenticated calls to a hosted platform. A deprecated SDK talking to a live API is where breakage accumulates first.

The third is the Node wrapper as a dependency. Installing @shopify/themekit pulls a package that then downloads a binary. In a locked-down CI environment, a package that downloads an executable at install time is a supply chain consideration that a native install from a package manager does not raise, and it is one of the reasons to prefer the wrapper only when you need the pinning it provides.

The fourth is scope. Theme Kit moves a theme between your machine and Shopify. It does not scaffold a theme, though the repository does contain a theme-template/ directory that hints at that, and it does not preview, lint or test Liquid. Those are things the Shopify CLI does today, which is precisely why the deprecation notice points there.

The fifth is that a deprecated tool still looks supported to a reader who skims. The README body, the features list, the command reference and the configuration reference all read like a current product, and the warning is a block at the top that a person scrolling to the install command will miss. Anyone evaluating this has to read the first paragraph.

Editorial conclusion

Theme Kit suits an existing project with a working Theme Kit setup that needs to keep running during a migration, and it is the wrong tool for anything new, because the README's own warning says parts of Theme Kit will become unsupported and may stop working soon. Before adopting it, read the deprecation notice at the top of the README rather than the feature list further down. Verify first that the Shopify CLI covers the commands your workflow depends on, and if you must keep Theme Kit, prefer the Node wrapper at @shopify/themekit so the binary version is managed by your lockfile rather than by whatever is on the machine.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. Shopify/themekit on GitHub