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'
|
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'
|
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'])
|
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}`)
|
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() {
|
2024-06-18 14:29:35 +00:00
|
|
|
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.')
|
|
|
|
}
|
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)
|
|
|
|
})
|