apps/backend/src/lib/local-emulator.ts (1)

73-84: Consider consolidating with CLI's renderConfigFile.

This implementation is nearly identical to packages/stack-cli/src/lib/stack-config-file.ts. Both validate, normalize with the same options, and produce the same output format. The only differences are the error types (StatusError vs CliError) and messages.

Consider extracting the core rendering logic to @stackframe/stack-shared and having both CLI and backend wrap it with their respective error handling. This would prevent the implementations from drifting apart.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/backend/src/lib/local-emulator.ts` around lines 73 - 84, Extract the
shared rendering logic into `@stackframe/stack-shared` as a single function (e.g.,
formatConfigExport or renderConfigCore) that accepts the raw config, runs
isValidConfig + normalize with the same options (onDotIntoNonObject: "ignore",
onDotIntoNull: "empty-object") and returns the export string (import + export
const config = defineStackConfig(...)); then update
apps/backend/src/lib/local-emulator.ts's renderConfigFile to call that shared
function and translate any thrown error into a StatusError with the existing
message, and similarly update packages/stack-cli/src/lib/stack-config-file.ts to
call the shared function and wrap errors in a CliError so both callers use the
identical core logic while preserving their specific error types.

packages/stack-shared/src/config-authoring.test.ts (1)

34-43: Make the enum-negative test fail for only the enum reason.

Line 38 uses @ts-expect-error, but the object is partial; that can let the test pass for a different type error. Include the same valid sibling fields and change only customerType to keep this assertion precise.

♻️ Suggested tightening

 defineStackConfig({
   payments: {
     items: {
       todos: {
+        displayName: "Todo Slots",
         // `@ts-expect-error` Invalid enum values should fail type-checking.
         customerType: "workspace",
       },
     },
   },
 });

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/stack-shared/src/config-authoring.test.ts` around lines 34 - 43, The
test using defineStackConfig currently marks customerType with //
`@ts-expect-error` but the surrounding object is partial which may allow other
type errors to satisfy the directive; update the test so the todos object
includes the same valid sibling fields (the required fields present in a normal
todos config) and change only payments.items.todos.customerType to the invalid
enum value ("workspace") so the `@ts-expect-error` fails solely for the enum
mismatch; locate the defineStackConfig call and adjust the payments.items.todos
object to be otherwise valid except for customerType.

packages/stack-shared/src/config-rendering.ts (1)

17-37: Consider adding a test for conflicting keys.

The tests cover normalization and invalid input rejection, but don't cover the scenario where keys conflict (e.g., {"a.b": "string", "a.b.c": "nested"}). Adding such a test would clarify the expected behavior.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/stack-shared/src/config-rendering.ts` around lines 17 - 37, Add a
unit test for renderConfigFileContent that asserts behavior when the input has
conflicting dotted keys (e.g., "a.b" vs "a.b.c"); locate renderConfigFileContent
in the test file and add a test case that either expects a thrown error
(toDocument the rejection) or expects a deterministic resolution (specify which
value wins), using expect(() =>
renderConfigFileContent(conflictingInput)).toThrow... or
expect(...).toContain... depending on the intended behavior; ensure the new test
name clearly describes "conflicting keys" so it complements the existing
normalization and invalid-input tests.

apps/e2e/tests/backend/endpoints/api/v1/internal/config-local-emulator.test.ts (1)

114-117: Brittle whitespace-dependent assertion.

The string match '"teams": {\n "allowClientTeamCreation": true\n }' is sensitive to exact formatting (newlines, indentation). If renderConfigFileContent changes its output style, this test will break even if the content is semantically correct.

Consider parsing the config object from the file and asserting on the parsed structure, similar to how cli.test.ts uses extractConfigObjectString + JSON.parse.

♻️ Suggested approach

     const fileContent = await fs.readFile(filePath, "utf-8");
     expect(fileContent).toContain('import type { StackConfig } from "@stackframe/stack-shared/config";');
-    expect(fileContent).toContain('"teams": {\n    "allowClientTeamCreation": true\n  }');
+    // Extract and parse the config object for a more robust assertion
+    const configMatch = fileContent.match(/export const config:\s*StackConfig\s*=\s*(.+);\s*$/s);
+    expect(configMatch).not.toBeNull();
+    const parsedConfig = JSON.parse(configMatch![1]);
+    expect(parsedConfig.teams).toEqual({ allowClientTeamCreation: true });

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/e2e/tests/backend/endpoints/api/v1/internal/config-local-emulator.test.ts`
around lines 114 - 117, The assertion is brittle because it depends on exact
whitespace in fileContent; instead extract the config object string from
fileContent (reuse the existing extractConfigObjectString helper used in
cli.test.ts), JSON.parse that string into an object, and assert on the parsed
shape (e.g., parsedConfig.teams.allowClientTeamCreation === true). Keep the
existing import line assertion but replace the raw string match with parsing via
extractConfigObjectString(fileContent) -> JSON.parse(...) and then use the
parsed object in assertions.

apps/e2e/tests/backend/endpoints/api/v1/internal/config-local-emulator.test.ts (1)

115-117: Prefer inline snapshots over brittle multiline toContain checks.

These assertions are sensitive to whitespace/formatting. A single inline snapshot is usually clearer and more stable for generated-file output checks.

♻️ Suggested refactor

-    const fileContent = await fs.readFile(filePath, "utf-8");
-    expect(fileContent).toContain('import type { StackConfig } from "@stackframe/js";');
-    expect(fileContent).toContain('"teams": {\n    "allowClientTeamCreation": true\n  }');
+    const fileContent = await fs.readFile(filePath, "utf-8");
+    expect(fileContent).toMatchInlineSnapshot(`
+"import type { StackConfig } from \\"@stackframe/js\\";
+
+export const config: StackConfig = {
+  \\"teams\\": {
+    \\"allowClientTeamCreation\\": true
+  }
+};
+"
+`);

Based on learnings: "When writing tests, prefer .toMatchInlineSnapshot over other selectors, if possible."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/e2e/tests/backend/endpoints/api/v1/internal/config-local-emulator.test.ts`
around lines 115 - 117, Replace the brittle multiline toContain checks on the
generated file string with a single inline snapshot assertion: capture the value
returned by await fs.readFile(filePath, "utf-8") (variable fileContent) and use
expect(fileContent).toMatchInlineSnapshot(`...`) containing the exact expected
file output; update the test in config-local-emulator.test.ts to remove the two
expect(...).toContain(...) lines and instead assert a single inline snapshot for
fileContent so formatting/whitespace changes are versioned in the snapshot.

apps/e2e/tests/backend/endpoints/api/v1/internal/local-emulator-project.test.ts (1)

88-89: Good assertion target; consider snapshotting this generated snippet.

This is a solid check for typed output, but toMatchInlineSnapshot will usually be easier to maintain than multiple toContain assertions.

♻️ Suggested refactor

-    expect(fileContent).toContain('import type { StackConfig } from "@stackframe/js";');
-    expect(fileContent).toContain("export const config: StackConfig =");
+    expect(fileContent).toMatchInlineSnapshot(`
+"import type { StackConfig } from \\"@stackframe/js\\";
+
+export const config: StackConfig = {
+  ...
+};
+"
+`);

Based on learnings: "When writing tests, prefer .toMatchInlineSnapshot over other selectors, if possible."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/e2e/tests/backend/endpoints/api/v1/internal/local-emulator-project.test.ts`
around lines 88 - 89, Replace the two .toContain assertions on fileContent with
a single .toMatchInlineSnapshot assertion: locate the test that calls
expect(fileContent).toContain('import type { StackConfig } ...') and
expect(fileContent).toContain("export const config: StackConfig ="), remove
those two expects and replace with
expect(fileContent).toMatchInlineSnapshot(`...`) containing the exact generated
snippet (the import line and the export const config block) so the generated
code is snapshot-tested as a single, maintainable inline snapshot.