Dev Console Aliases - #3841

What

Adds @osdk/aliases, a new package holding the alias runtime, and a browser-safe entry point so Developer Console apps can read installer-supplied configuration.

Why

Custom aliases let an app author declare env-var-style config that a Marketplace installer fills in at install time. Two problems with hosting that in @osdk/functions:

1. @osdk/functions peer-depends on @osdk/client, so a browser app reading a JSON file inherited a client version floor. This failed npm install in a Developer Console app's build with ERESOLVE.
2. Aliases are meant to span Functions, transforms, Slate, and Developer Console. Living inside one runtime's package misrepresents that.

@osdk/aliases has no dependencies on @osdk/client or @osdk/functions, so neither problem can recur by construction.

Public API

import { Aliases } from "@osdk/aliases/experimental";

const aliases = await Aliases.load();
const apiBaseUrl = aliases.custom("apiBaseUrl");

Aliases.load() may be called once in main.tsx for application-wide loading or only where aliases are needed. Repeated and concurrent calls share the cached load and return the same reader. Once loaded, custom() is a synchronous lookup. The reader shape also leaves room for additional alias namespaces later.

Node code (Functions) keeps using the filesystem runtime, unchanged:

import { Aliases } from "@osdk/functions"; // or "@osdk/aliases/node"
Aliases.custom("myAlias");

Entry points:

The browser API sits behind experimental so the import path states its stability at every call site, matching @osdk/client, @osdk/react, and @osdk/react-components.

Resolution behavior

Aliases.load() fetches and caches aliases before returning a synchronous reader. Loading is explicit because browsers cannot perform a synchronous network read. Applications decide where to handle the initial loading and any error; a future React hook can wrap the same API without changing the underlying behavior.

Two files can supply values:

Callers do not choose between them. The deployment config is tried first. The declaration file is used only when the deployment config appears absent: a 404 or a 200 containing an HTML document, as single-page-app hosts may rewrite unknown paths to index.html. Any other failure throws instead of silently substituting the author's defaults for the installer's values.

Compatibility

@osdk/functions re-exports the Node runtime through a local facade at src/aliases/index.ts, so its public Aliases namespace is unchanged. The facade uses explicit named re-exports to accommodate API Extractor.

etc/functions.report.api.md is updated to reflect that the namespace members now resolve from @osdk/aliases/node.

Testing

pnpm turbo test           --filter=@osdk/aliases     # 100 tests
pnpm turbo typecheck      --filter=@osdk/aliases --filter=@osdk/functions
pnpm turbo transpileTypes --filter=@osdk/aliases --filter=@osdk/functions
pnpm turbo check-api      --filter=@osdk/functions
pnpm --dir packages/aliases lint
npx mrl check

transpileTypes is listed separately because typecheck runs with --emitDeclarationOnly false and does not exercise --isolatedDeclarations; declaration-emit errors can therefore pass typecheck and still fail the build.

The browser tests cover successful loading and lookup, concurrent and repeated loads, cache reset and retry, missing aliases, malformed responses, value validation, deployment/default fallback behavior, inherited JavaScript property names, and the experimental export boundary.

Verified end to end against a Foundry stack:

• Declared two aliases in an app's public/resources.json, deployed the site, packaged it as a Marketplace product, and installed it with overrides. The running site reads the installer's values rather than the declared defaults.
• Upgraded the installation to a new product version. The installer's values persist, which is why the alias input-shape ID excludes the application version.

Packaging an application with no aliases is covered by unit tests but has not yet been verified end to end.