Migrate to StartOS SDK 2.0.5 - #1
Merged
Merged
Conversation
Bump @start9labs/start-sdk 1.5.3 -> 2.0.6 and typescript -> 6.0.3, and
collapse tsconfig.json onto the SDK's tsconfig.base.json (ES2022, module
preserve, moduleResolution bundler).
Two 2.0 breaking changes reach this package:
- sdk.serviceInterface.getOwn is removed. getNonLocalUrls now goes through
sdk.host.getOwn, walking host.bindings[port].interfaces to the 'ui'
interface; addressInfo arrives pre-filled. Note the host id is the
MultiHost id ('ui-multi'), not the interface id.
- SubContainer.of() is now lazy and synchronous, so the awaits are dropped;
caddySub.rootfs is a promise on the lazy handle and is awaited at the
Caddyfile write. It materializes with the declared mounts, so the /data
volume mount on teapotSub is unchanged.
Bump the packaging revision 0.1.0:0 -> :1. No data migration, so current.ts
is edited in place rather than spun off into a new version file.
Refresh the vendored s9pk.mk from the SDK tarball. It is carried per-package
at the repo root, so bumping the npm pin does not update it, and this copy
was still the 1.5.3-era file: no check-deps ordering on the build targets,
dead docs URLs, no git/jq dep checks, no SDK lint gate at all, and an
install/publish target requiring a flat host:/registry: in
~/.startos/config.yaml (which is why `make install` failed against a
workspace whose hosts live in the nested workspace config). Ran the lint
runner before adopting it -- exit 0, so the newly-enabled gate is clean.
CI: drop the "Pin start-cli v0.4.0-beta.9" step from both workflows. It
existed only because the package was SDK 1.5.3, and that CLI cannot pack a
2.0.x package -- leaving it would have broken the release build. build.yml
returns to the shared Start9 reusable workflow, which it was inlined away
from solely to host that pin.
Also annotate the manifest's alerts.install block as dead in README/TODO.
'alerts' is absent from SDKManifest and is dropped at pack time, so the
install alert never renders -- but this predates 2.0 rather than being a
migration regression: the released v0.1.0_0 s9pk, packed on SDK 1.5.3, has
has("alerts") == false in its built manifest too. The throwaway-account
warning it carried is already in instructions.md and the Add Session action,
so no user-facing content is or was lost.
Verified: tsc, lint, ncc and s9pk pack (x86_64 + aarch64), plus device-testing
of install, upgrade in place over 0.1.0:0, sessions, browsing, RSS, Set
Primary URL and Basic Auth -- covering both APIs above, neither of which fails
at compile time. That testing was done against the 2.0.5 build; the published
2.0.5 and 2.0.6 tarballs carry byte-identical runtime code (they differ only
in CHANGELOG.md, README.md, package.json and s9pk.mk), so it carries over.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
stupleb
force-pushed
the
migrate-sdk-2.0.5
branch
from
July 18, 2026 19:16
724c3cc to
c871b2c
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps
@start9labs/start-sdk1.5.3 → 2.0.5 (and TypeScript → 6.0.3), packaging revision0.1.0:0→0.1.0:1.Breaking changes that reach this package
sdk.serviceInterface.getOwnis removed.getNonLocalUrlsgoes throughsdk.host.getOwn, walkinghost.bindings[port].interfacesto theuiinterface;addressInfoarrives pre-filled. Note the host id is the MultiHost id ('ui-multi'), not the interface id — getting this wrong returns an empty list rather than an error.SubContainer.of()is now lazy and synchronous, so theawaits are dropped;caddySub.rootfsis a promise on the lazy handle and is awaited at the Caddyfile write. It materializes with the declared mounts, so the/datavolume mount is unchanged.CI
Drops the
Pin start-cli v0.4.0-beta.9step from both workflows. It existed only because the package was SDK 1.5.3, and that CLI cannot pack a 2.0.5 package — leaving it would have broken the release build.build.ymlreturns to the shared Start9 reusable workflow, which it was inlined away from solely to host that pin.Also
Annotates the manifest's
alerts.installblock as dead inREADME.md/TODO.md.alertsis absent fromSDKManifestand is dropped at pack time, so the install alert never renders — but this predates 2.0 rather than being a migration regression: the releasedv0.1.0_0s9pk, packed on SDK 1.5.3, hashas("alerts") == falsein its built manifest too. The throwaway-account warning it carried is already ininstructions.mdand the Add Session action, so no user-facing content is or was lost. The block itself is left in place for a separate decision.Verification
tsc,nccands9pk pack(x86_64 + aarch64), plus device-testing of install, upgrade in place over0.1.0:0, sessions, browsing, RSS, Set Primary URL and Basic Auth — covering both APIs above, neither of which fails at compile time.🤖 Generated with Claude Code