Elvis Pranskevichus

[python-analysis] Add requirements.txt parsing via `uv-requirements-txt` (#15498) Add `parse-requirements-txt` WIT export for parsing requirements.txt files into structured data (PEP 508 specifiers, VCS URLs, extras, markers, index URLs, etc.). The upstream uv crate has several dependencies that are either too heavy for WASM or pull in async runtimes. These are satisfied by minimal stub crates (same interface, trivial internals): - `uv-client-stub`: offline-only connectivity (no HTTP client) - `uv-configuration-stub`: --no-binary/--only-binary option types - `uv-distribution-types-stub`: requirement wrapper types - `uv-fs-stub`: path utilities + file reading via host-bridge - `fs-err-stub`: absorbs tokio feature flag without pulling in tokio, (`fs-err` is only used in tests, but Cargo pulls it nonetheless). The host-bridge `read-file` function enables the upstream parser to resolve `-r`/`-c` includes through the WASM host. All async I/O resolves synchronously via the host-bridge, so a single-poll executor (`Waker::noop()`) drives the upstream async API. Also rename current `uv-fs-patch` to `uv-fs-stub` for naming consistency. Before: Binary Overview ─────────────── Total (code+data): 1,721,148 bytes (1.64 MB) Code: 499.5 KB ████████▉ 29.7% Data: 1.15 MB █████████████████████ 70.3% .rodata: 1.13 MB .data+.bss: 25.2 KB Top 10 Crates by Size ───────────────────── total code data % ───────────────────────────────────────────────────────────────────────────────────────────── 1. unicode_names2 823.9 KB 4.8 KB 819.1 KB ████████████████████ 49.0% 2. encoding_rs 169.4 KB 40.6 KB 128.8 KB ████ 10.1% 3. core 134.7 KB 88.9 KB 45.8 KB ███ 8.0% 4. unicode_normalization 111.0 KB 2.2 KB 108.8 KB ██ 6.6% 5. ruff_python_parser 106.7 KB 96.2 KB 10.5 KB ██ 6.3% 6. alloc 55.6 KB 55.3 KB 239 B █ 3.3% 7. data_encoding 43.6 KB 42.6 KB 971 B █ 2.6% 8. vercel_python_analysis 23.8 KB 21.9 KB 2.0 KB 1.4% 9. uv_pypi_types 22.1 KB 20.3 KB 1.8 KB 1.3% 10. std 17.1 KB 13.9 KB 3.1 KB 1.0% After: Binary Overview ─────────────── Total (code+data): 3,227,476 bytes (3.08 MB) Code: 1.43 MB █████████████▉ 46.4% Data: 1.65 MB ████████████████ 53.6% .rodata: 1.54 MB .data+.bss: 115.1 KB Top 10 Crates by Size ───────────────────── total code data % ───────────────────────────────────────────────────────────────────────────────────────────── 1. unicode_names2 823.9 KB 4.8 KB 819.1 KB ████████████████████ 26.1% 2. regex_syntax 420.5 KB 113.0 KB 307.5 KB ██████████ 13.3% 3. core 289.8 KB 240.9 KB 48.8 KB ███████ 9.2% 4. regex_automata 246.7 KB 228.8 KB 17.9 KB █████ 7.8% 5. encoding_rs 169.4 KB 40.6 KB 128.8 KB ████ 5.4% 6. alloc 116.5 KB 116.0 KB 502 B ██ 3.7% 7. unicode_normalization 111.0 KB 2.2 KB 108.8 KB ██ 3.5% 8. ruff_python_parser 106.7 KB 96.2 KB 10.5 KB ██ 3.4% 9. aho_corasick 92.1 KB 84.4 KB 7.7 KB ██ 2.9% 10. icu_normalizer 75.1 KB 6.4 KB 68.7 KB █ 2.4%

cli: Extract global config helpers to a new package, validate config (#16186) Current global configuration logic is firmly embedded in the main CLI package which makes it hard to reuse in library bits that might want to rely on configuration in library code. Remedy this by pulling the configuration lookup and I/O logic to the new `@vercel/cli-config` package. While here, add config validation via `@effect/schema`. This is a behavior change because the CLI will now fail loudly on invalid config data instead of continuing and possibly failing in worse ways somewhere deeper in the command implementation. Unknown config properties are ignored and passed through for 180-degree compat with versions of the CLI or other consumers. Additionally, while working on this I realized that a bunch of places were reading and writing global configuration directly and not via the `Client` interface, so I fixed some of those (notably `auto-install-agentic`).

Upgrade a few straddlers to TypeScript 5.9 (#16253) I missed a few spots in #16169. This finishes the job. Markdown doc changes are due to the necessary `typedoc` upgrade.

[python] Add `diagnostics` callback to produce `project-manifest.json` (#15373) Introduce a `diagnostics` export to the Python builder that returns a `package-manifest.json` file containing structured project metadata: runtime, resolved Python version, and a full dependency inventory. `generateProjectManifest` collects dependencies from all `pyproject.toml` sources (`project.dependencies`, `optional-dependencies`, `dependency-groups`), classifies each as direct or transitive, and resolves versions and source info (registry, git, path, etc.) from the `uv.lock` file. Transitive dependencies inherit scopes from their direct dependents via BFS through the lock file's dependency graph. A dependency that appears in multiple groups (e.g. both `main` and `dev`) accumulates all scopes. The manifest is only generated when a `uv.lock` file is available; builds without one (e.g. custom install commands) skip manifest creation. The `diagnostics` callback is wired into the builder contract so the build system can collect the manifest after the build completes. Example `package-manifest.json`: ```json { "version": "20260304", "runtime": "python", "runtimeVersion": { "requested": ">=3.10", "requestedSource": "pyproject.toml", "resolved": "3.12" }, "dependencies": [ { "name": "flask", "type": "direct", "scopes": ["main"], "requested": "flask>=2.0", "resolved": "3.1.0", "source": "registry", "sourceUrl": "https://pypi.org" }, { "name": "werkzeug", "type": "transitive", "scopes": ["main"], "resolved": "3.0.0" } ] } ``` <!-- VADE_RISK_START --> > [!NOTE] > Low Risk Change > > This PR adds a new diagnostics feature to generate a project manifest JSON file containing dependency metadata; it only adds new code paths for metadata collection without modifying existing build logic, auth, or database schemas. > > - New `diagnostics.ts` file with `generateProjectManifest` function to produce metadata JSON > - Exports `parsePep508` and adds `specifier` field to existing types for version tracking > - Comprehensive test coverage added in `diagnostics.test.ts` > > ^{Risk assessment for [commit 218f4e8](https://github.com/vercel/vercel/commit/218f4e8bd8252ea15d6d8592fc10a9250832b0f1).} <!-- VADE_RISK_END -->

[python-analysis] Stub unicode/IDNA crates to reduce WASM size (#15499) Move IDNA and Unicode normalization operations out of the WASM binary and into the Node.js host via the new `host-utils` WIT interface. This eliminates ICU/Unicode lookup tables from the compiled component, using the host's native `URL` and `String.prototype.normalize` instead. Specifically: - `idna-stub`: delegates domain-to-ASCII/Unicode to host - `unicode-normalization-stub`: delegates NFC/NFD/NFKC/NFKD to host - `unicode-names2-stub`: returns Unicode replacement char (U+FFFD) as this is only used by the ruff parser to normalize Unicode name escapes in Python string literals (`\N{CAPITAL LETTER L}`) which is irrelevant to the analyses. - `host-bridge`: codegen crate for WASM host import bindings - `wasm-test-support`: test harness for running WASM tests with host fns Because the stub crates delegate to the JS host at runtime, their tests must run inside a WASM component with the real `host-utils` wired in. A custom `wasm-test-runner.mjs` is added and registered via `.cargo/config.toml` as the `cargo test --target wasm32-wasip2` runner. The runner transpiles each test binary with jco, instantiates it with the same `host-utils` implementation used in production, so `cargo test` works seamlessly for WASM targets. Before: Binary Overview ─────────────── Total (code+data): 2,865,491 bytes (2.73 MB) Code: 1.24 MB █████████████▌ 45.4% Data: 1.49 MB ████████████████▍ 54.6% .rodata: 1.39 MB .data+.bss: 106.5 KB Top 10 Crates by Size ───────────────────── total code data % ──────────────────────────────────────────────────────────────────────────────────────────── 1. unicode_names2 823.9 KB 4.8 KB 819.1 KB ████████████████████ 29.4% 2. regex_syntax 420.5 KB 113.0 KB 307.5 KB ██████████ 15.0% 3. core 255.8 KB 220.4 KB 35.5 KB ██████ 9.1% 4. regex_automata 246.7 KB 228.9 KB 17.9 KB █████ 8.8% 5. unicode_normalization 111.0 KB 2.2 KB 108.8 KB ██ 4.0% 6. ruff_python_parser 106.7 KB 96.2 KB 10.5 KB ██ 3.8% 7. alloc 96.3 KB 95.8 KB 502 B ██ 3.4% 8. aho_corasick 92.1 KB 84.4 KB 7.7 KB ██ 3.3% 9. icu_normalizer 75.1 KB 6.4 KB 68.7 KB █ 2.7% 10. uv_pep508 73.3 KB 66.4 KB 6.9 KB █ 2.6% After: Binary Overview ─────────────── Total (code+data): 1,716,626 bytes (1.64 MB) Code: 1.18 MB █████████████████████▋ 72.1% Data: 467.7 KB ████████▎ 27.9% .rodata: 369.0 KB .data+.bss: 98.7 KB Top 10 Crates by Size ───────────────────── total code data % ───────────────────────────────────────────────────────────────────────────────────────────── 1. regex_syntax 420.5 KB 113.0 KB 307.5 KB ████████████████████ 25.1% 2. regex_automata 246.7 KB 228.9 KB 17.9 KB ███████████ 14.7% 3. core 239.0 KB 203.6 KB 35.5 KB ███████████ 14.3% 4. ruff_python_parser 106.3 KB 95.9 KB 10.4 KB █████ 6.3% 5. alloc 94.3 KB 93.8 KB 502 B ████ 5.6% 6. aho_corasick 92.1 KB 84.4 KB 7.7 KB ████ 5.5% 7. uv_pep508 73.3 KB 66.4 KB 6.9 KB ███ 4.4% 8. uv_pep440 33.3 KB 28.6 KB 4.7 KB █ 2.0% 9. url 31.8 KB 29.6 KB 2.3 KB █ 1.9% 10. vercel_python_analysis 31.2 KB 28.7 KB 2.5 KB █ 1.9%

auth: Make it possible to store CLI credentials in OS keychain (#16083) Storing credentials in OS keychain is materially safer than plaintext files: - keychains are encrypted at rest by the OS, hence protect from cold-boot attacks; - access to the keychain can be mediated by OS security controls (login context, prompts etc); - credentials are less likely to be exposed by accident (e.g dotfile commits, agent reads etc). Specific changes: CLI credentials storage is made configurable via the new `"authTokenStorage"` global config var. Possible values are - `"keyring"` -- store credentials in the system keychain, via `@napi-rs/keyring` which is a Node binding for `keyring-rs`, both of which are widely used (the latter by Codex); - `"file"` -- store credentials in `<config-dir>/auth.json`, which is the current behavior and is still the default; - `"auto"` -- use keyring, if available, otherwise fall back to "file". When credentials are successfully written to a keychain, the previous copy in plaintext file is removed to avoid confusion. Additionally, credentials are auto-migrated on storage changes on read, which would allow us to change the default method in the future without breaking sessions.

[python] Consolidate Python version resolution into `python-analysis` (#15368) Replace ad-hoc version parsing and file discovery in the Python builder with the structured APIs from `@vercel/python-analysis`. <!-- VADE_RISK_START --> > [!NOTE] > Low Risk Change > > This PR refactors Python version resolution logic by consolidating ad-hoc parsing into the python-analysis package, with no changes to authentication, authorization, database schema, or security controls. > > - Refactors version selection from inline parsing to structured `selectPythonVersion` API > - Adds new exports and helper functions in python-analysis package > - Extensive test coverage added for version selection scenarios > > ^{Risk assessment for [commit ad04692](https://github.com/vercel/vercel/commit/ad04692e96f13405a4c4dac212277fed52a08f96).} <!-- VADE_RISK_END -->

[python-analysis] Replace `pip-requirements-js` with WASM-based uv parser (#15513) Switch requirements.txt parsing from the npm `pip-requirements-js` package to the WASM component's uv-based parser, removing the npm dependency and expanding test coverage.

[python] Force-bundle packages without compatible wheels instead of failing (#15587) The Python runtime installs externalized packages at cold start using `uv sync --no-build`, which refuses to build from source. If a package has no pre-built wheel compatible with the Lambda platform, runtime installation fails. Currently the builder runs a blanket `--no-build` check and throws a hard error if *any* package lacks wheels, even though the problematic packages could simply be bundled into the Lambda package. With this change the dependency externalizer checks each public package's wheels (parsed from `uv.lock`) against the target platform using uv's logic.

cli-exec: New package to locate and run the CLI from libraries (#16234) `@vercel/cli-exec` is a small helper library that locates and runs the Vercel CLI. Its main purpose is so that we can use the CLI as a trusted helper in cases where we need to read sensitive data that only the CLI binary is authorized to do (e.g keychain access for tokens).

[python] Fix env marker-excluded deps erroneously flagged as lacking wheels (#15668) Dependencies guarded by PEP 508 environment markers that exclude the target platform (e.g. pywin32 with `sys_platform == 'win32'`) are being checked for Linux wheel compatibility and incorrectly marked for force-bundling. Fix by traversing the `uv.lock` dependency graph from the project root, evaluating markers via uv's `MarkerTree::evaluate()` (exposed through the WASM module), to determine which packages are actually reachable on the target platform before checking wheel compatibility.

[python] Add litellm proxy support (#15313) The `litellm` support is in a form of a new quirk that informs the `prisma` quirk added earlier about the location of litellm's persistence schema. Other than that, the litellm proxy works out of the box with no additional configuration other than placing `litellm_config.yaml` at the root of the project (configurable with `CONFIG_FILE_PATH` env var). Other litellm env vars are naturally supported, refer to upstream documentation. <!-- VADE_RISK_START --> > [!NOTE] > Low Risk Change > > This PR adds a new litellm proxy support feature with a new quirk module, test fixtures, and comprehensive test coverage - no security, auth, schema, or critical business logic changes. > > - New litellm quirk module for build-time config detection > - Test fixtures and extensive unit tests for litellm integration > - Changeset documentation for patch release > > ^{Risk assessment for [commit c4e1a8c](https://github.com/vercel/vercel/commit/c4e1a8c6ec905ba1181de0fe971df1197082affb).} <!-- VADE_RISK_END -->

Upgrade repo-wide TypeScript to 5.9 (#16169) All node builders have already been switched to TypeScript 5 (see #14252 and #14892), so this should be safe.

Revert "auth: Make it possible to store CLI credentials in OS keychain (#16083)" (#16154) This reverts commit 24686d0eac8d8fbca2dfda475fc92a0ed7526210. Breaks deploys: Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/vercel/8f0c162/node_modules/@vercel/cli-auth/credentials-store.js' imported from /vercel/8f0c162/node_modules/vercel/dist/chunks/chunk-TUXGNXJZ.js --------- Co-authored-by: Jeff See <jeffsee.55@gmail.com>

[python-runtime] Report fatal init errors via IPC `unrecoverable-error` message (#15319) Before this change, fatal errors during module import (missing handler, import failures) were written to stderr and lost — SFR never saw them because the functions runtime only forwards IPC messages. `_fatal()` now sends an `unrecoverable-error` IPC message before exiting, which is one of the two message types the functions runtime accepts before the `server-started` handshake. While here: - Add `_fatal_exc()` helper for fatal-with-traceback (used for import errors) - Replace all `_stderr(); exit(1)` patterns with `_fatal()` - Extract `_flush_init_log_buf()` to deduplicate the IPC-ready + buffer flush sequence <!-- VADE_RISK_START --> > [!NOTE] > Low Risk Change > > This PR improves error reporting in the Python runtime by sending IPC messages for fatal errors instead of only writing to stderr, with no changes to security, authentication, or database schemas. > > - Adds `_send_unrecoverable_error()` to send IPC messages before exit on fatal errors > - Refactors `_stderr(); exit(1)` patterns to use unified `_fatal()` helper > - Adds test coverage for new `UnrecoverableErrorMessage` IPC message type > > ^{Risk assessment for [commit 46cc231](https://github.com/vercel/vercel/commit/46cc23103db2ade80b2300e980d639eb7848d2a6).} <!-- VADE_RISK_END -->

[cli/build] Namespace diagnostics keys by builder and service workspace (#15399) Prefix diagnostics file keys with the builder name (e.g. `python/`) and service workspace path for multi-service or multi-builder builds, so that diagnostics from different builders or services do not collide. Single-project, single-builder builds remain unprefixed. <!-- VADE_RISK_START --> > [!NOTE] > Low Risk Change > > This PR adds JSON schema validation for package manifests and namespaces diagnostics keys by builder/workspace to prevent collisions in multi-service builds - purely additive build tooling changes with no auth, database, or billing impact. > > - Adds `packageManifestSchema` JSON schema for validating builder diagnostics output > - Namespaces diagnostics keys with builder name and workspace prefix for multi-service builds > - Aggregates per-builder `package-manifest.json` files into single `project-manifest.json` > > ^{Risk assessment for [commit 2d558e0](https://github.com/vercel/vercel/commit/2d558e04cef48b241424d782bb6daeaa60c7422d).} <!-- VADE_RISK_END -->

cli/project/token: Add JSON output mode, print to stdout (#16156) Add `--format=json` to output the OIDC token as `{"token": "..."}` for reliable parsing. Additionally, fix a bug where token was printed to stderr instead of stdout.

fix(ci/frameworks): verify demo public access via logs redirect (#16137) Stop relying on API access and query build logs endpoint directly to check if a framework demo is public.

ci: Lint workflows with zizmor, require 3rd party actions to be pinned (#16140) Actions are a massive supply-chain attack vector. Require all third-party (non-Github) actions to be pinned. Enforce this via zizmor in `lint-actions` job.

[python] Check PyPI instead of `git diff` to decide whether to publish (#15452) The previous logic compared `pyproject.toml` versions between `HEAD` and `HEAD^`, which meant that if a "Version Packages" PR merged but failed to publush, a subsequent release attempt would see the version as "unchanged" and skip publishing permanently leading to breakage. Make the script query PyPI directly to check whether the current version is already published, making the decision based on actual PyPI state rather than some fragile heuristics.