tldraw/scripts/publish-vscode-extension.ts

65 lines
2.2 KiB
TypeScript
Raw Normal View History

Set up automatic VS Code publishing (#3905) When pushing to production branch we now also package and publish a new version of the VS Code extension. We get the last version from VS Code marketplace and update the package.json with that version. We don't commit that to the repo though (see the discussion below). I added `VSCE_PAT` secret (my own personal access token from the dev.azure.com), which will expire in 1 year. This is used when running the publish command. Some more info here: - [Publishing from CI](https://code.visualstudio.com/api/working-with-extensions/continuous-integration#github-actions) - Publishing uses `VSCE_PAT` env variable ![image](https://github.com/tldraw/tldraw/assets/2523721/df971c57-5197-4525-bc58-d50dd4bd8f3c) ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [ ] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [x] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [ ] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [x] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Release Notes - Automate publishing of the VS Code extension.
2024-06-17 14:14:42 +00:00
import { existsSync, readFileSync, writeFileSync } from 'fs'
import path from 'path'
Do a pre-release of the VS code extension for merges to main. (#3957) VS Code extension can do [pre-releases](https://code.visualstudio.com/api/working-with-extensions/publishing-extension#prerelease-extensions). This would make it easier to test unreleased version of the extension (thanks @ds300 [for the suggestion](https://github.com/tldraw/tldraw/pull/3905#pullrequestreview-2122897351)) Tried the pre-release option manually, to see how it works: https://github.com/tldraw/tldraw/assets/2523721/880fe0a2-3f29-405b-9862-b30594cf5334 There's a drawback in that we need to update version even for pre-releases as they do not support other versioning schemes atm. I decided to go with patch versions for pre-releases and minor versions for regular releases. Feels like a better UX than having a really high patch number due to bumping it on every PR. > We only support major.minor.patch for extension versions, semver pre-release tags are not supported. So, if you publish a major.minor.patch-tag release to the Marketplace, it will be treated as major.minor.patch, and the tag will be ignored. Versions must be different between pre-release and regular releases. That is, if 1.2.3 is uploaded as a pre-release, the next regular release must be uploaded with a distinct version, such as 1.2.4. Full semver support will be available in the future. ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [ ] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [x] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [ ] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [x] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Release Notes - Release a pre-release when we merge changes to main.
2024-06-26 07:23:25 +00:00
import { parse } from 'semver'
Set up automatic VS Code publishing (#3905) When pushing to production branch we now also package and publish a new version of the VS Code extension. We get the last version from VS Code marketplace and update the package.json with that version. We don't commit that to the repo though (see the discussion below). I added `VSCE_PAT` secret (my own personal access token from the dev.azure.com), which will expire in 1 year. This is used when running the publish command. Some more info here: - [Publishing from CI](https://code.visualstudio.com/api/working-with-extensions/continuous-integration#github-actions) - Publishing uses `VSCE_PAT` env variable ![image](https://github.com/tldraw/tldraw/assets/2523721/df971c57-5197-4525-bc58-d50dd4bd8f3c) ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [ ] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [x] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [ ] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [x] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Release Notes - Automate publishing of the VS Code extension.
2024-06-17 14:14:42 +00:00
import { exec } from './lib/exec'
import { makeEnv } from './lib/makeEnv'
Do a pre-release of the VS code extension for merges to main. (#3957) VS Code extension can do [pre-releases](https://code.visualstudio.com/api/working-with-extensions/publishing-extension#prerelease-extensions). This would make it easier to test unreleased version of the extension (thanks @ds300 [for the suggestion](https://github.com/tldraw/tldraw/pull/3905#pullrequestreview-2122897351)) Tried the pre-release option manually, to see how it works: https://github.com/tldraw/tldraw/assets/2523721/880fe0a2-3f29-405b-9862-b30594cf5334 There's a drawback in that we need to update version even for pre-releases as they do not support other versioning schemes atm. I decided to go with patch versions for pre-releases and minor versions for regular releases. Feels like a better UX than having a really high patch number due to bumping it on every PR. > We only support major.minor.patch for extension versions, semver pre-release tags are not supported. So, if you publish a major.minor.patch-tag release to the Marketplace, it will be treated as major.minor.patch, and the tag will be ignored. Versions must be different between pre-release and regular releases. That is, if 1.2.3 is uploaded as a pre-release, the next regular release must be uploaded with a distinct version, such as 1.2.4. Full semver support will be available in the future. ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [ ] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [x] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [ ] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [x] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Release Notes - Release a pre-release when we merge changes to main.
2024-06-26 07:23:25 +00:00
import { nicelog } from './lib/nicelog'
Set up automatic VS Code publishing (#3905) When pushing to production branch we now also package and publish a new version of the VS Code extension. We get the last version from VS Code marketplace and update the package.json with that version. We don't commit that to the repo though (see the discussion below). I added `VSCE_PAT` secret (my own personal access token from the dev.azure.com), which will expire in 1 year. This is used when running the publish command. Some more info here: - [Publishing from CI](https://code.visualstudio.com/api/working-with-extensions/continuous-integration#github-actions) - Publishing uses `VSCE_PAT` env variable ![image](https://github.com/tldraw/tldraw/assets/2523721/df971c57-5197-4525-bc58-d50dd4bd8f3c) ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [ ] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [x] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [ ] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [x] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Release Notes - Automate publishing of the VS Code extension.
2024-06-17 14:14:42 +00:00
// VSCE_PAT needs to be set. It is used by the vsce publish command.
Do a pre-release of the VS code extension for merges to main. (#3957) VS Code extension can do [pre-releases](https://code.visualstudio.com/api/working-with-extensions/publishing-extension#prerelease-extensions). This would make it easier to test unreleased version of the extension (thanks @ds300 [for the suggestion](https://github.com/tldraw/tldraw/pull/3905#pullrequestreview-2122897351)) Tried the pre-release option manually, to see how it works: https://github.com/tldraw/tldraw/assets/2523721/880fe0a2-3f29-405b-9862-b30594cf5334 There's a drawback in that we need to update version even for pre-releases as they do not support other versioning schemes atm. I decided to go with patch versions for pre-releases and minor versions for regular releases. Feels like a better UX than having a really high patch number due to bumping it on every PR. > We only support major.minor.patch for extension versions, semver pre-release tags are not supported. So, if you publish a major.minor.patch-tag release to the Marketplace, it will be treated as major.minor.patch, and the tag will be ignored. Versions must be different between pre-release and regular releases. That is, if 1.2.3 is uploaded as a pre-release, the next regular release must be uploaded with a distinct version, such as 1.2.4. Full semver support will be available in the future. ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [ ] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [x] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [ ] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [x] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Release Notes - Release a pre-release when we merge changes to main.
2024-06-26 07:23:25 +00:00
const env = makeEnv(['VSCE_PAT', 'TLDRAW_ENV'])
Set up automatic VS Code publishing (#3905) When pushing to production branch we now also package and publish a new version of the VS Code extension. We get the last version from VS Code marketplace and update the package.json with that version. We don't commit that to the repo though (see the discussion below). I added `VSCE_PAT` secret (my own personal access token from the dev.azure.com), which will expire in 1 year. This is used when running the publish command. Some more info here: - [Publishing from CI](https://code.visualstudio.com/api/working-with-extensions/continuous-integration#github-actions) - Publishing uses `VSCE_PAT` env variable ![image](https://github.com/tldraw/tldraw/assets/2523721/df971c57-5197-4525-bc58-d50dd4bd8f3c) ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [ ] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [x] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [ ] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [x] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Release Notes - Automate publishing of the VS Code extension.
2024-06-17 14:14:42 +00:00
const EXTENSION_DIR = 'apps/vscode/extension'
async function updateExtensionVersion() {
const extensionInfoJsonPath = path.join(EXTENSION_DIR, 'extension.json')
if (!existsSync(extensionInfoJsonPath)) {
throw new Error('Published extension info not found.')
}
const extensionInfoJson = JSON.parse(readFileSync(extensionInfoJsonPath, 'utf8'))
const version = extensionInfoJson.versions[0].version
if (!version) {
throw new Error('Could not get the version of the published extension.')
}
Do a pre-release of the VS code extension for merges to main. (#3957) VS Code extension can do [pre-releases](https://code.visualstudio.com/api/working-with-extensions/publishing-extension#prerelease-extensions). This would make it easier to test unreleased version of the extension (thanks @ds300 [for the suggestion](https://github.com/tldraw/tldraw/pull/3905#pullrequestreview-2122897351)) Tried the pre-release option manually, to see how it works: https://github.com/tldraw/tldraw/assets/2523721/880fe0a2-3f29-405b-9862-b30594cf5334 There's a drawback in that we need to update version even for pre-releases as they do not support other versioning schemes atm. I decided to go with patch versions for pre-releases and minor versions for regular releases. Feels like a better UX than having a really high patch number due to bumping it on every PR. > We only support major.minor.patch for extension versions, semver pre-release tags are not supported. So, if you publish a major.minor.patch-tag release to the Marketplace, it will be treated as major.minor.patch, and the tag will be ignored. Versions must be different between pre-release and regular releases. That is, if 1.2.3 is uploaded as a pre-release, the next regular release must be uploaded with a distinct version, such as 1.2.4. Full semver support will be available in the future. ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [ ] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [x] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [ ] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [x] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Release Notes - Release a pre-release when we merge changes to main.
2024-06-26 07:23:25 +00:00
const semVer = parse(version)
if (!semVer) {
throw new Error('Could not parse the published version.')
}
const release = env.TLDRAW_ENV === 'production' ? 'minor' : 'patch'
const nextVersion = semVer.inc(release).version
nicelog(`Updating extension version from ${version} to ${nextVersion}`)
Set up automatic VS Code publishing (#3905) When pushing to production branch we now also package and publish a new version of the VS Code extension. We get the last version from VS Code marketplace and update the package.json with that version. We don't commit that to the repo though (see the discussion below). I added `VSCE_PAT` secret (my own personal access token from the dev.azure.com), which will expire in 1 year. This is used when running the publish command. Some more info here: - [Publishing from CI](https://code.visualstudio.com/api/working-with-extensions/continuous-integration#github-actions) - Publishing uses `VSCE_PAT` env variable ![image](https://github.com/tldraw/tldraw/assets/2523721/df971c57-5197-4525-bc58-d50dd4bd8f3c) ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [ ] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [x] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [ ] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [x] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Release Notes - Automate publishing of the VS Code extension.
2024-06-17 14:14:42 +00:00
const packageJsonPath = path.join(EXTENSION_DIR, 'package.json')
if (!existsSync(packageJsonPath)) {
throw new Error("Could not find the extension's package.json file.")
}
const packageJson = JSON.parse(readFileSync(packageJsonPath, 'utf8'))
packageJson.version = nextVersion
writeFileSync(packageJsonPath, JSON.stringify(packageJson, null, '\t') + '\n')
}
async function packageAndPublish() {
await exec('yarn', ['lazy', 'run', 'build', '--filter=packages/*'])
Do a pre-release of the VS code extension for merges to main. (#3957) VS Code extension can do [pre-releases](https://code.visualstudio.com/api/working-with-extensions/publishing-extension#prerelease-extensions). This would make it easier to test unreleased version of the extension (thanks @ds300 [for the suggestion](https://github.com/tldraw/tldraw/pull/3905#pullrequestreview-2122897351)) Tried the pre-release option manually, to see how it works: https://github.com/tldraw/tldraw/assets/2523721/880fe0a2-3f29-405b-9862-b30594cf5334 There's a drawback in that we need to update version even for pre-releases as they do not support other versioning schemes atm. I decided to go with patch versions for pre-releases and minor versions for regular releases. Feels like a better UX than having a really high patch number due to bumping it on every PR. > We only support major.minor.patch for extension versions, semver pre-release tags are not supported. So, if you publish a major.minor.patch-tag release to the Marketplace, it will be treated as major.minor.patch, and the tag will be ignored. Versions must be different between pre-release and regular releases. That is, if 1.2.3 is uploaded as a pre-release, the next regular release must be uploaded with a distinct version, such as 1.2.4. Full semver support will be available in the future. ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [ ] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [x] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [ ] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [x] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Release Notes - Release a pre-release when we merge changes to main.
2024-06-26 07:23:25 +00:00
switch (env.TLDRAW_ENV) {
case 'production':
await exec('yarn', ['package'], { pwd: EXTENSION_DIR })
await exec('yarn', ['publish'], { pwd: EXTENSION_DIR })
return
case 'staging':
await exec('yarn', ['package', '--pre-release'], { pwd: EXTENSION_DIR })
await exec('yarn', ['publish', '--pre-release'], { pwd: EXTENSION_DIR })
return
default:
throw new Error('Workflow triggered from a branch other than main or production.')
}
Set up automatic VS Code publishing (#3905) When pushing to production branch we now also package and publish a new version of the VS Code extension. We get the last version from VS Code marketplace and update the package.json with that version. We don't commit that to the repo though (see the discussion below). I added `VSCE_PAT` secret (my own personal access token from the dev.azure.com), which will expire in 1 year. This is used when running the publish command. Some more info here: - [Publishing from CI](https://code.visualstudio.com/api/working-with-extensions/continuous-integration#github-actions) - Publishing uses `VSCE_PAT` env variable ![image](https://github.com/tldraw/tldraw/assets/2523721/df971c57-5197-4525-bc58-d50dd4bd8f3c) ### Change Type <!-- ❗ Please select a 'Scope' label ❗️ --> - [ ] `sdk` — Changes the tldraw SDK - [ ] `dotcom` — Changes the tldraw.com web app - [ ] `docs` — Changes to the documentation, examples, or templates. - [x] `vs code` — Changes to the vscode plugin - [ ] `internal` — Does not affect user-facing stuff <!-- ❗ Please select a 'Type' label ❗️ --> - [ ] `bugfix` — Bug fix - [ ] `feature` — New feature - [ ] `improvement` — Improving existing features - [ ] `chore` — Updating dependencies, other boring stuff - [ ] `galaxy brain` — Architectural changes - [ ] `tests` — Changes to any test code - [x] `tools` — Changes to infrastructure, CI, internal scripts, debugging tools, etc. - [ ] `dunno` — I don't know ### Release Notes - Automate publishing of the VS Code extension.
2024-06-17 14:14:42 +00:00
}
async function main() {
await updateExtensionVersion()
await packageAndPublish()
}
main().catch(async (err) => {
console.error(err)
process.exit(1)
})