Skip to content

Instantly share code, notes, and snippets.

@panoply

panoply/overview.md

Created February 27, 2024 16:06
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save panoply/3650b40e290a7abb89277c9aabd0c9b1 to your computer and use it in GitHub Desktop.
Save panoply/3650b40e290a7abb89277c9aabd0c9b1 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
overview.md

EXPORT FROM DISCORD

Original score with help from the talented Dave Warrington.

I may have very well solved the version control paradigm for themes. It’s not possible in CI but publishing from local machines to your store/s is now roughly a 15s task. Quick little breakdown here:

As I’ve touched on before, I went down the versioning rabbit hole in an attempt to bring some sanity to this nexus. What I’ve come out on I think is pretty lean and does not get in the way. I’ve gone over a dozen ways to approach this but it feels as if this is now the final solution. Appropriating via CI shouldn’t be too difficult to apply. There are a couple commands which have relation to theme versioning and releases or better put “operations” for theme releases and publishing.

This will be a long thread - hope you get a spare 5 minutes to go over and give thoughts.

--build ~ (Syncify Build)

Running this command, as per current versions will build a theme from your source.

--export ~ (Syncify Export)

Running this command will generate an “export” which essentially is just an archived .zip version.

--export <patch|minor|major> ~ (Syncify Versioning)

Running this command will apply a version bump to theme exports. Version bumps are simple and will use your root package.json as a reference (or read/write source-of-truth). Running something like syncify -e minor will increment the version in your package.json from something like 1.0.0 to 1.1.0 - from here, an export operation will ensue. The export will generate a .zip file and will write it to the defined directory path you’ve provide in your syncify config.

Demonstration Example:

$ syncify -e minor # -e is an alias for --export

The above command will write the following in your projects workspace.

| export
| | v1
|   | 1.0.0.zip
|   | 1.1.0.zip  # Here will be latest version

The package.json file version will also be updated in this process and you have the option to apply increment to your settings_schema.json file version too.

Exports are essentially ready-to-deploy compressions of themes, it is how you’d go about versioning. The cool thing about this approach is I am only explaining the surface level here. It goes deeper, in the sense that you can configure Syncify to apply overwrites in “patch” version exports to remote stores so on and so forth. Moving onto the actual “publishing” logic.

--publish ~ (Syncify Theme Upload)

Previously, I approached this with an incorrect manner, wherein you’d execute a full theme “upload” which was was too time expensive. This logic will still remain as a feature, but the better tactic moving forward will be the --publish flag. Running this will do a few things (respecting the versioning approach I’ve introduced) here is how is executes. Running this command will create a new theme in your store with the version number as the theme name, eg: v1.1.0 - it is rather elegant because publishing is done directly from your machine, here is how works under the hood:

  1. Syncify will create a temporary server on port 80 (or one you specify)
  2. An ngrok tunnel is established which exposes your latest version export (e.g: 1.1.0.zip)
  3. Syncify publishing the theme to your store, you have the option to go live with it in preview mode.

This operation takes about 10s to complete. You can configure theme “deprecations” and replacements to apply during publishment so as to never exceed the number of theme limits available to shopify stores. You may also prefer to use custom theme naming variations or alternatively apply an alias publishment tactic (e.g: production, staging, live) etc etc. I am only describing the defaults here.

All of these command operations can run isolated as I’ve described, however say you want use 1 command to do all the above operations, this is when you’d simple reach for --release which would do the following:

$ syncify -r minor # -r is an alias for --release
  1. Build the theme from source
  2. Export and apply a version bump
  3. Publish the theme to your store

Releases will complete in about 15 seconds. Both the --publish and --release calls can write to multiple stores with no problem.

What this solves and its practicality in real world cases means that developers will be able to streamline there theme updates and versioning. It borrows from the semantic approach but also is flexible enough to allow developers to override and produce their own publishment flows for their specific use cases.

Matters of “rolling back” to previous versions is also solved with this tactic because of the important export operation which needs to take place. What this means is, that for every theme version you publish/release an exported .zip will exist. You’d need only to refer to a previous export version in your Github.

When you couple it with the development approach in Syncify, what you get is a complete solution. You can develop, test, and deploy all from your machine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment