Move the CLI-level integration tests to a TypeScript e2e suite

[skyrpex]

A TypeScript/Vitest e2e suite in test/e2e/, driving the built bin/lstk binary and
importing no lstk source. 225 tests, ~75s for the full run.

It is not additive: the Go integration tests it replaces are deleted in the same PR.
Against main, test/integration goes from 427 test functions across 55 files to 269
across 40 (14,758 → 10,623 lines), and loses its AWS SDK dependency entirely. Which
suite owns what — and, for every Go test that stayed behind, why it could not move — is
in test/e2e/PORTING.md.

The test-e2e CI job is still outside the release job's needs:. That now has to
change before this merges, since for the migrated areas it is the only suite covering
the CLI boundary.

Why

test/integration already runs the binary and reports to CI, so the gap it leaves is
readability, not capability. The question was whether a suite whose tests read as
statements about user-visible behaviour is worth a second toolchain in a Go repo.

What it asserts, and what it refuses to

Tests describe what a user observes from the CLI. Assertions on mechanism were
deliberately not ported:

• Telemetry (assertCommandTelemetry) — which analytics event fired is invisible to
  a user. This is the one thing the deleted Go tests uniquely covered, so it is
  consolidated rather than dropped: test/integration/command_telemetry_test.go asserts
  per-command event name and exit code in one table.
• Container introspection (docker inspect of Config.Env, HostConfig.Binds) —
  replaced by the CLI-observable equivalent where one exists, e.g. restart --persist
  is asserted through the • Persistence: Enabled line.
• Token storage — nothing in test/e2e touches the credential store;
  keyring: "file" | "system" only picks which backend the binary uses. Every
  assertion the Go tests made by reading the keyring is now made through behaviour:
  logging in means start stops demanding credentials and a second login says
  "You're already logged in"; a failed login storing nothing means start still
  demands them and a retry reopens the browser. That is stronger than reading the
  store — it shows the credential is usable — and it holds for whichever backend
  the binary picked. It is also more robust: the two Go tests that did reach in wrote
  through the test process's own $HOME while running lstk under a temp one, so they
  passed on Linux CI and failed locally.

Exact output is asserted with a toPrintExactly matcher rather than inline snapshots:
the expectation is authored rather than recorded, no vitest -u can quietly bless a
regression, and it composes with test.each (inline snapshots throw inside it).

What was deleted, and what stayed

Deleted outright: json_envelope, exit_code, non_interactive, completion, docs,
aws_completion, terraform_cmd, logs, reset, volume, stop, restart,
logout, status, endpoint_url, endpoint_url_https.

--endpoint-url (#419) landed after this port was written and moves across as a unit —
36 cases. Its eighteen rejection cases collapse into one table: every command with no
remote equivalent refuses all three sources (the flag, LSTK_ENDPOINT_URL,
AWS_ENDPOINT_URL) with the same sentence, so asserting the whole line is both shorter
and stricter than the substring checks it replaces.

lstk aws completion (#424) arrived the same way, and its bash-driver case depended on a
helper inside completion_test.go. Both files moved rather than one being restored to
prop up the other: the delegation to aws_completer is CLI-observable and needs no
Docker, and completion.test.ts already drives the generated script under a bare bash.

config_test.go likewise gained TestConfigWithInvalidContainerNameFails from #420.
That one went the other way — rejected at config load, no daemon and no token, so it was
ported to tests/config.test.ts next to its port is required sibling. Its companion
TestStartCommandUsesCustomContainerName stays in Go: it needs a real start plus a
container inspect.

Trimmed, keeping only what TypeScript cannot reach — json_flag (2 of 7: the az
tables, which need a completed lstk setup azure), aws_cmd (3 of 18: spinner timing
under a PTY), config (1 of 12: container env introspection),
emulator_type (7 of 10), emulator_select (7 of 9), start (34 of 36), login
(1 of 4: TestDeviceFlowSuccess, kept for its telemetry assertion).

Untouched: snapshots, IaC end-to-end, most of start, extensions and signal forwarding,
update/install, license, az/setup azure/awsconfig.

Two Go tests turned out to be vacuous: TestConfigWithUnknownFieldsIsAccepted and
TestConfigWithMissingOptionalTagSucceeds assert config acceptance via lstk config path, which never parses the file — they pass against a nonexistent path. The ports use
lstk logout, which actually calls config.Get().

Findings worth their own PRs

Asserting whole output instead of substrings surfaced inconsistencies no test was
checking. None are fixed here:

1. Two failure-rendering paths. ErrorEvent failures print to stdout with ==>
   next steps; several user-facing errors instead fall through to the unstyled stderr
   fallback with no guidance — volume clear/reset confirmation-required, the
   missing-port config error, the config.yaml migration message, the terraform
   override-file refusal. CLAUDE.md calls that fallback "not the preferred path".
2. lstk stop/restart not-running errors offer no next step; status/aws do.
3. lstk config bogus gives no "See help" hint; lstk bogus does.
4. "not running" wording differs: logs says "LocalStack AWS Emulator is not
   running", reset says "LocalStack is not running".
5. --type renders the config path two ways — absolute on first run, literal
   ~/.config/lstk/config.toml when switching.
6. runningNonAWSEmulator (cmd/iac.go) fabricates a container config instead of
   reading the user's, unlike its neighbour resolveAWSContainer. Harmless for the
   common case (the image fallback rescues it), but a custom image plus a non-latest
   tag defeats both probes and produces the misleading "AWS not running".
7. Windows omits the endpoint from "Docker is not available" — POSIX prints cannot connect to ... at unix:///…, Windows prints only the suggestions, so a Windows user
   cannot tell a wrong DOCKER_HOST from a stopped daemon.
8. lstk login checks for a TTY before the already-logged-in short-circuit
   (cmd/login.go), so a scripted lstk login while authenticated says "login requires
   an interactive terminal" and exits 1 instead of "You're already logged in".

Toolchain

Node ≥ 26 (pinned in test/e2e/.node-version) and pnpm. Type-erasable TypeScript only
(erasableSyntaxOnly), typechecked by TypeScript 7, .ts import specifiers.

Terminal tests are mandatory rather than best-effort: node-pty is a required
dependency, and a missing binding fails the run instead of silently skipping half the
suite — which is what happened when it was optional and npm blocked its build script.
It is pinned to an exact prerelease because 1.1.0 ships a non-executable spawn-helper
on macOS and no Linux prebuilds; test/e2e/README.md records the measurements behind
that pin. LSTK_E2E_REQUIRE_ALL=1 turns a missing prerequisite into a failure on the
Linux CI leg, so coverage cannot erode into silent skips.

Speed

163s → ~33s over three changes, each measured (the suite has since grown to ~70s,
almost all of it the browser-login PTY tests, which cannot be made much faster):

• docker pull costs ~1.8s even when the image is present (it still checks the registry
  digest); a local docker image inspect is ~15ms.
• The stand-in container ran sleep infinity, which ignores SIGTERM, so every
  lstk stop test waited out Docker's 10s grace period. Trapping TERM: 12s → 1.3s.
• Most container tests now mint their own emulator identity (privateEmulator()), since
  ContainerConfig.Name() only returns the canonical name for tag latest — so they no
  longer queue behind one machine-wide lock.

Tests still needing that lock keep it with the reason inline. The subtle case: any
container built from a real localstack/* image reference is visible to every test's
"is an emulator running" check, because discovery falls back to matching a known image
exposing 4566 and ContainerPort() is hardcoded to 4566 regardless of config. Getting
that wrong made the suite fail ~2 runs in 9; the fixed suite ran clean 8 times
consecutively.

For the reviewer

• Container behaviour is verified on exactly one CI leg. Ubuntu has Docker and the
  token; macOS and Windows runners cannot run Linux containers, so 63 and 72 tests
  respectively skip there. Roughly 51 tests could stop running on those legs without
  anything going red. Enabling Docker elsewhere was investigated and is a dead end —
  docker/setup-docker-action does not work on ARM macOS, and hosted Windows runners
  cannot run Linux containers at all — so the proposal is a per-platform skip budget
  asserted in CI, in a follow-up.
• Two prerequisites are gated, not assumed. The https --endpoint-url tests need
  certificate trust an exec'd lstk actually reads, and Go's x509 verifier only takes
  that from SSL_CERT_FILE on Linux (darwin uses Security.framework, Windows its own
  store) — the same gate they had in Go. The "status reports the bound port" test needs
  a daemon that can publish on the 127.0.0.2 loopback alias, which Docker Desktop's VM
  networking refuses, so it is probed and skipped rather than left flaky. Both are
  requirement()-checked, so LSTK_E2E_REQUIRE_ALL=1 turns either into a hard failure
  on the CI leg that has everything. The https cases were verified on Linux in a
  container before landing rather than shipped unrun.
• The Windows login journey cannot work: pkg/browser invokes rundll32 rather than
  a shimmable script. No loss against today, since login_test.go already skips Windows.
• test-e2e must be promoted to a required check (and into the release job's
  needs:) as part of merging this, not after.
• Two pre-existing macOS-local failures in logout_test.go
  (TestLogoutCommandNotesWhenEmulatorStillRunning,
  TestLogoutCommandReportsBothEmulatorsWhenMultipleRunning) were confirmed to fail at
  the merge-base too. Untouched here.

Review: please review rather than self-merge. It is large, introduces a second
toolchain, and it deletes Go tests — the strategy was not discussed beforehand.

Not linked to a Linear issue yet — happy to attach one.

Co-authored-by: Claude noreply@anthropic.com

[silv-io]

Hi @skyrpex, I noticed this PR and I wonder what the goals here would be?
From what I can tell it is mostly a translation to another language (+ introducing a second language to the code base)

What would the benefits be besides that some people will find it more readable? (from my perspective Go would be the more readable option FWIW :P)

However, I can list some negatives of porting:

1. The existing suite is battle-tested for half a year and works fine so far. An entirely ported test suite might introduce some inconsistencies which we don't know about yet.
2. You only need knowledge of one language to interact with the repo at the moment. This change will need knowledge of JS/TS and its build system and runtime.
3. Carole and I would lose the holistic knowledge of this repo/project and the knowledge would be silo-ed off to the owning team. So if something bigger comes up we'd need to consider at least 3 people to plan and debug things so everything works smoothly
4. The PR still leaves some parts Go while moving things to TS, so we are just introducing a 8k line new test suite in one PR while weakening the existing one which we still run.

I don't want to outright say no to this, and I see benefits of having TS testing here (especially around testing interaction with the VS Code extension), but so far I don't fully understand the argument of why this big change is necessary.