refactor: read and write config toml in TypeScript

[christierney]

Intent

Migrate configuration reading and writing from Go API calls to a pure TypeScript toml module in the VSCode extension. This removes three HTTP round-trips to the Go backend for operations that only need local file I/O, and moves us toward reducing the extension's dependency on the Go subprocess.

Type of Change

• Refactor
• Bug fix (schema misspelling)

Approach

Updated type definitions and the schema to match current behavior:

• Consolidated TS types to match Go and schema (remove dead types/fields, add missing ones)
• Removed dead Go types (Schedule, AccessType, ConnectAccessControl) and unreachable code in content.go
• Fixed schema: auth_type in integration_requests (was camelCase), add additionalProperties: false to integration_requests items

Added a new src/toml/ module with seven files:

• errors.ts — ConfigurationLoadError class and error factory functions
• convertKeys.ts — Bidirectional snake_case ↔ camelCase key conversion, preserving user-defined keys in environment and integration_requests[].config
• compliance.ts — Port of Go's ForceProductTypeCompliance() for Connect Cloud
• loader.ts — Reads TOML, validates against the JSON schema (using ajv), applies defaults
• writer.ts — Validates, converts to snake_case, strips empty leaf values, writes TOML
• discovery.ts — File discovery (listConfigFiles), single/batch/recursive loading, path resolution
• validate.ts — Shared setup for TOML validator function

The public API surface is five exports: loadConfiguration, loadAllConfigurations, loadAllConfigurationsRecursive, writeConfigToFile, and ConfigurationLoadError. Internal helpers stay exported on their source files for intra-module use and tests, but are not re-exported from the barrel.

All functions that produce Configuration objects accept (projectDir, rootDir) where projectDir is relative (e.g., "." or "subdir") and rootDir is the absolute workspace root. Path resolution to absolute paths for file I/O happens inside the module. This matches the Go convention where ProjectDirFromRequest resolves relative dir parameters against the workspace base.

After replacing all callsites, the three Go API handlers (GET /configurations, GET /configurations/{name}, PUT /configurations/{name}) and their tests were deleted. The shared configDTO/configLocation types remain as they're used by other endpoints.

A copy of the JSON schema is bundled at src/toml/schemas/posit-publishing-schema-v3.json, identical to the Go source of truth. A comment in the schema test notes the need to keep them in sync.

Key design decisions:

• No intermediate store — callsites call toml functions directly
• Writer returns the written Configuration — no write-then-read round-trip
• Loader throws on error; discovery functions catch and collect errors for the UI
• src/toml/ has no vscode imports — it's pure Node.js
• stripEmpty only removes leaf values (undefined, null, empty strings), never parent objects, because the schema conditionally requires section headers like [r] even when all fields are empty

User Impact

No user-facing behavior change. Configuration reading and writing now happens directly in the extension process instead of through HTTP calls to the Go backend.

Automated Tests

[ed: there's probably more now, I've made some improvements since ]

a bunch of new tests in src/toml/:

• Key conversion (19 tests) — snake/camel round-trip, preservation of user-defined keys
• Schema validation (32 tests) — validates the bundled JSON schema against known valid/invalid configs
• Loader (19 tests) — happy path, TOML parse errors, schema errors, defaults, comments, business rules
• Writer (14 tests) — round-trip fidelity, snake_case output, comments, stripEmpty, compliance, unknown type handling, empty section preservation
• Discovery (22 tests) — file listing, single/batch/recursive loading, relative projectDir, error collection, skip rules
• Compliance (13 tests) — cleanup and field modifications based on target product (connect or cloud)
• Errors (13 tests) — error factories and formatting of validation error messages

Existing state.test.ts tests were rewritten to mock the toml module instead of the API client.

Directions for Reviewers

I recommend reading through the new toml/ directory first and then reviewing the updates to the extension code.

I am working my way through these manual tests:

• Open workspace with existing config — sidebar loads, no errors
• Open workspace with configs in a subdirectory — configs discovered and selectable
• Open workspace with no configs — loads cleanly
• Open workspace with malformed .toml — config shows error state, no crash
• Select a deployment — config loads, files/packages/secrets populate (no 404s)
• Open config dropdown — shows configs matching current entrypoint
• New deployment for Python app — config created with [python] section, snake_case keys
• New deployment for R Shiny app — config created with [r] section, no schema error
• Re-associate: select existing config — config list loads
• Re-associate: create new config — file written, deployment uses it
• Subdirectory project — all above work, no absolute paths in debug console

Checklist

• I have updated the root CHANGELOG.md to cover notable changes.

yes, only for the auth_type schema fix. The rest should not be user-facing.

[christierney]

The Go code has a more complicated setup for excluding files: see https://github.com/posit-dev/publisher/blob/main/internal/bundles/matcher/walker.go

That code is also used for excluding files from bundles, etc. It didn't seem worth implementing all that for just loading configs and the above skiplist seemed sufficient to me, but I'm interested in feedback on this point.

[christierney]

This function is attempting to produce useful error messages from TOML validation failures, and to make them match what the Go validator returns (e.g. <key>: not allowed or <key>: missing property). The e2e tests look for these specific error messages. We could decide to let the messages from ajv through if we want, but this keeps the behavior and test changes smaller. In any case we need to do some processing to extract actionable info from the array of validation errors, even if we don't coerce the messages into the Go form.

[christierney]

this was redundant as filterConfigurationToValidAndType already filters out errors

[christierney]

this is a fix for a pre-existing bug I found while testing. This path was not setting a product type, so you'd end up with an invalid config TOML (with 'product_type = '').

The new deployment flow already does this:

publisher/extensions/vscode/src/multiStepInputs/newDeployment.ts

Lines 856 to 857 in 9367e0f

	newDeploymentData.entrypoint.inspectionResult.configuration.productType =
	getProductType(newOrSelectedCredential.serverType);

[zackverham]

thanks for fixing this!