Publishing new versions

Publishing new versions

We use changesets (opens in a new tab) to orchestrate the versioning of our packages. Here's how you define and publish a new version:

  1. Run npx changeset and choose which packages are being upgraded as major/minor/patch
    • Keep in mind that we aren't yet doing major changes. While we don't hit 1.0.0, all minor patches can be breaking
  2. Run yarn update-package-versions to apply these changes to the package.json of packages
  3. Make sure the versions of the toolkit packages are the latests in the templates' package.json
  4. Run yarn publish-packages to build the packages, get the templates inside of @tinloof/remix-cli and push these packages to npm
    • You'll need edit access to the packages on npm

Documenting a new version

After you publish an update following the guide above, you'll need to communicate the changelog. If your version doesn't affect the template, such as a bug-fix in @tinloof/sanity-toolkit or a new helper in js-toolkit, you're good to go. Just make sure those looking for these fixes and features are notified.

However, if changes were made to the template, you'll need to document which files users must add/remove/update, following this process:

  1. Create a new blank project with the CLI to a new folder, following the guide above
  2. From the changelog reference repository (opens in a new tab), create a new branch from the branch of the most recent release of that given template.
    • It's crucial that you start from the most recent as that will reveal which files changed
  3. In this new branch, paste the entirety of the CLI-created project, overwriting all conflicting files
  4. Commit everything and publish the branch with the name v0${VERSION}-${TEMPLATE_NAME}
    • Example: v012-base - version 0.12 of the base template
    • Example: v015-shopify - version 0.15 of the shopify template
  5. Open the branch comparison UI in Github to compare the previous version's branch and the new one, following the pattern:
  6. From the comparison, document each change in a new Notion page from the CLI project page (opens in a new tab)
    • Duplicate the last release's changelog and work from that

That's it! Feel free to reach out to Henrique on Slack if you need help 😉