feat: add TypeScript TOML config loader and consolidate types by christierney · Pull Request #3655 · posit-dev/publisher

christierney · 2026-03-05T19:22:01Z

Intent

Add a TypeScript-native TOML configuration loader that matches Go's config.FromFile behavior, as a building block for migrating away from the Go backend.

Fixes #3651
Fixes #3652

Type of Change

- Bug Fix
- New Feature
- Breaking Change
- Documentation
- Refactor
- Tooling

Approach

Add smol-toml, ajv, ajv-formats dependencies for TOML parsing and JSON Schema validation
Create src/toml/ module: loader, key converter, error factories, and JSON schema copy
Consolidate TS types to match Go and schema (remove dead types/fields, add missing ones)
Remove dead Go types (Schedule, AccessType, ConnectAccessControl) and unreachable code in content.go
Fix schema: auth_type in integration_requests (was camelCase), add additionalProperties: false to integration_requests items

User Impact

Minimal. Schema now accurately reflects what the code produces. The schema is also stricter now, so in theory if somebody had hand-edited their integration requests TOML and introduced errors, they will get better error messaging.

Automated Tests

New tests for new code. I used the existing Go config loading tests as a guide for coverage.

Directions for Reviewers

The type cleanup is hopefully fairly easy to follow. Unused stuff that got deleted should be easy to prove as unused since little to no code referenced it. It's a little hard to read the JSON schema manually and see that the TS types now align more closely with it, but the code for parsing and validating TOML helps prove that.

Nothing is calling the TS toml code yet (other than tests) but I tried to design it to be a clean building block for replacing the APIs, and there are some "downstream compatibility" tests to help demo that.

A note on the schema change: this could be considered breaking, since I'm renaming an existing field, but I think it's ok for a couple reasons:

the extension code actually uses the snake_case field name, not the camelCase the schema referenced. So nobody would have the camelCase version unless they wrote it by hand. This change brings the schema in line with reality.
the integration requests type was not doing strict field checking prior to this change, so we could argue that the type was not fully locked down until now

The schema now lives in two places (under the Go code and under TS). I think this is acceptable for now as we're in flux. We should clean this up as we get rid of the Go side.

Checklist

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

Mentioned the schema change since that is potentially user-visible. The rest is all internal changes.

christierney · 2026-03-05T19:23:02Z

extensions/vscode/src/api/types/configurations.ts

 export type ConfigurationLocation = {
  configurationName: string;
  configurationPath: string;
-  configurationRelPath: string;


nobody was using this. We can always add it back if we want it but I think it's confusing

christierney · 2026-03-05T19:26:00Z

extensions/vscode/src/toml/schema.test.ts

@@ -0,0 +1,253 @@
+// Copyright (C) 2026 by Posit Software, PBC.


this is based on a similar test on the Go side---it's basically checking that we have defined our schema correctly. (It's probably not comprehensive).

should we make a follow-up ticket to try to make this more comprehensive? These seem like good tests.

Maybe? I'm not sure about the approach which feels a little haphazard. But it is nice to prove the schema does what we think.

christierney · 2026-03-05T19:27:25Z

extensions/vscode/tsconfig.json

    "target": "ES2023",
    "outDir": "out",
    "lib": ["ES2023", "DOM"],
+    "resolveJsonModule": true,


required for loading the JSON schema file

christierney · 2026-03-05T19:27:39Z

internal/clients/connect/content.go

 		Description: cfg.Description,
 	}
 	if cfg.Connect != nil {
-		if cfg.Connect.AccessControl != nil {


due to validation, it was impossible for this to ever be not nil

zackverham · 2026-03-05T19:33:58Z

extensions/vscode/src/toml/convertKeys.test.ts

+  });
+
+  it("passes through already-camelCase keys unchanged", () => {
+    const result = convertKeysToCamelCase({


does this test actually validate camelCase keys?

it's validating that keys which are already camelCase (authType, loadFactor, defaultImageName) get passed through unchanged

ohhh - yes, ok. Keys, not values. sorry, disregard

zackverham · 2026-03-05T19:35:14Z

extensions/vscode/src/toml/convertKeys.test.ts

+  });
+
+  it("preserves environment keys (user-defined)", () => {
+    const result = convertKeysToCamelCase({


does this actually test that we aren't camelCasing things? Should we include some snake_casing in this test to make the fact that things aren't changing more clear?

MY_API_KEY and DATABASE_URL are there, or are you thinking there should be lower_case fields?

I got mixed up on keys vs values, disregard!

christierney · 2026-03-05T19:35:54Z

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}

zackverham · 2026-03-05T19:45:12Z

extensions/vscode/src/toml/loader.test.ts

+    expect(isConfigurationError(result)).toBe(false);
+    const cfg = result as Configuration;
+
+    // validate defaults to true (matches Go New())


I think these code comments are helpful for now - eventually, we will want to probably want to make a sweep-through and delete the go references once the go implementation is gone.

zackverham · 2026-03-05T19:48:25Z

extensions/vscode/src/toml/schema.test.ts

+// Copyright (C) 2026 by Posit Software, PBC.
+
+import { describe, expect, it } from "vitest";
+import Ajv2020 from "ajv/dist/2020";


is it correct that we are pulling something that seems to be versioned for 2020?

that's the version of JSON-schema we use:

publisher/internal/schema/schemas/posit-publishing-schema-v3.json

Line 2 in 2755bb6

"$schema": "https://json-schema.org/draft/2020-12/schema",

also the most current version

zackverham · 2026-03-05T19:53:51Z

this all makes sense to me - looks good.

I don't know why that arm build step is failing - its failing everywhere, currently investigating.

extensions/vscode/src/toml/convertKeys.ts

dotNomad

Thanks for that change 🎉

Add a TypeScript-native TOML configuration loader that matches Go's config.FromFile behavior, as a building block for migrating away from the Go backend. - Add smol-toml, ajv, ajv-formats dependencies for TOML parsing and JSON Schema validation - Create src/toml/ module: loader, key converter, error factories, and JSON schema copy - Consolidate TS types to match Go and schema (remove dead types/fields, add missing ones) - Remove dead Go types (Schedule, AccessType, ConnectAccessControl) and unreachable code in content.go - Fix schema: auth_type in integration_requests (was camelCase), add additionalProperties: false to integration_requests items Fixes #3651 Fixes #3652 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Co-authored-by: Jordan Jensen <jordan.jensen@posit.co>

christierney · 2026-03-09T15:11:07Z

#3662 includes these changes

christierney requested a review from a team as a code owner March 5, 2026 19:22

christierney requested review from dotNomad, m-- and zackverham March 5, 2026 19:22

christierney commented Mar 5, 2026

View reviewed changes

zackverham reviewed Mar 5, 2026

View reviewed changes

zackverham approved these changes Mar 5, 2026

View reviewed changes

dotNomad reviewed Mar 5, 2026

View reviewed changes

extensions/vscode/src/toml/convertKeys.ts Outdated Show resolved Hide resolved

dotNomad approved these changes Mar 5, 2026

View reviewed changes

christierney and others added 3 commits March 5, 2026 16:33

remove unnecessary type assertion

d5b9146

Co-authored-by: Jordan Jensen <jordan.jensen@posit.co>

remove a couple other unneeded Record types

250556d

christierney force-pushed the chris/type-consolidation branch from e35e6a3 to 250556d Compare March 5, 2026 21:33

christierney closed this Mar 9, 2026

		@@ -0,0 +1,253 @@
		// Copyright (C) 2026 by Posit Software, PBC.

Conversation

christierney commented Mar 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Intent

Type of Change

Approach

User Impact

Automated Tests

Directions for Reviewers

Checklist

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

christierney commented Mar 5, 2026

Code review

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zackverham commented Mar 5, 2026

Uh oh!

Uh oh!

dotNomad left a comment

Choose a reason for hiding this comment

Uh oh!

christierney commented Mar 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

christierney commented Mar 5, 2026 •

edited

Loading