Automate deployment

[orta]

I built a nightly deploy tool which we use in the svelte language-tools monorepo which would work perfect for this repo. On top of that it was on my todo to create orta/monorepo-deploy-nightly#6 which is useful for both

[octref]

Sure 👍

[stefanprobst]

is there a nightly shiki build on npm? npm info shiki does not seem to show it.

[muenzpraeger]

@orta @octref Any thoughts if I take a stab on the GitHub actions to make this happen?

Current behavior:

• Isolated, scheduled job to update grammars
  • fails hard when grammar is not available (no updates for subsequent grammars)
  • doesn't update semver patch for shiki
• Isolated, scheduled job to update themes
  • fails hard when theme is not available (no updates for subsequent themes)
  • doesn't update semver patch for shiki
• Isolated, on commit-to-main job to publish to npm
  • doesn't do anything for/with the scheduled grammar/theme updates as no semver update

Proposed behavior:

• Couple (or combine) workflows for grammars and themes
  • Don't fail hard, instead auto-create issue for failed theme or grammar (easier tracking, no impact on other grammars/themes)
  • Increase patch version of shiki if changes exist
  • Commit changes
  • Create GitHub release with change history
    • This could eventually replace the current Changelog, to reduce future manual maintenance
  • Publish to npm

[octref]

@muenzpraeger Looks great 👍 Doing it in two parts would be best, eg first the "don't fail hard" part, then the commit/version/publish flow. I still think fetching grammar/theme and publishing should be separate actions.

[muenzpraeger]

@octref Agree in the separation. The coupling I was thinking about to trigger version/publication via a workflow event after grammar/theme updates.

Although I'm wondering about the right balance for auto-publication. I mean, even with only a weekly one it could be like 52 patch versions/year on the main package. Or maybe the way would be to separate grammars/themes into a dedicated package.

[octref]

I don't know about another package though – I still believe people should download one package and be able to start using it. However, one structure this could take is:

• Have a theme/language nightly package, that you can use with the shiki main package
• Have a workflow that send PR to merge latest theme/language into the main shiki package

[muenzpraeger]

I'd say I'll get as a first step a PR up for issue creation in case of grammar/theme update issues.

And we'll discuss with v1 on nightlies. Now that there are breaking changes on the table it's way easier to draw ideas. ;-)

My thinking re: packages was conceptually like this.

{
  "name": "@shiki/core",
  "version": "1.0.0",
  "dependencies": {
    "@shiki/themes": "^1.0.0",
    "@shiki/grammars": "^1.0.0"
  }
}

That way theme/grammar could have nightly packages, and "core" would not need them.

And taking it further... implementing the package configs via the project config. Which could then also be a standard way for people to add their own customizations.

{
   "name": "@muenzpraeger/my-custom-shiki-theme",
   "version": "0.2.1",
   "shiki": {
      "themes": {
         "my-custom-theme": "./my-custom-theme.json"
      }
   }
 }

Just a thought. ;-)

[octref]

Yeah, similar to what I'm thinking. @shiki/themes should export a list of themes, and people can duck theme.