phoenix-typescript

Enforces TypeScript naming, typing, and import conventions across the Phoenix monorepo.

11.3k|1.1k|Updated Nov 9, 2022
One-click install
npx skills add https://github.com/Arize-ai/phoenix --skill phoenix-typescript
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: phoenix-typescript
Source: https://github.com/Arize-ai/phoenix/tree/main/.agents/skills/phoenix-typescript
Command: npx skills add https://github.com/Arize-ai/phoenix --skill phoenix-typescript

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Inconsistent TypeScript style across a large monorepo leads to unreadable code, hidden runtime bugs from unsafe types, and bloated bundles. This Skill gives AI assistants and reviewers a single, authoritative set of conventions for all TypeScript code in the Phoenix repository.

Core Features & Use Cases

  • Naming and Function Standards: Enforces self-documenting variable names, verb-prefixed booleans, action-verb function names, and object destructuring for multi-parameter functions with JSDoc annotations.
  • Type Safety Rules: Requires type guards for union narrowing, bans any in favor of unknown, and mandates Partial<Record<K, V>> or V | undefined for lookup maps to prevent silent undefined access.
  • Purity and Import Discipline: Requires pure utilities to accept overridable defaults (e.g., now, DEFAULT_ constants) instead of reading ambient state, and mandates lodash path imports for tree shaking.
  • Use Case: When writing a new utility in js/packages/phoenix-client or refactoring a React component in js/app/, apply these rules so the code passes review without style-related rework.

Quick Start

Review my new TypeScript function in js/app and rewrite it to follow the Phoenix TypeScript conventions.

Frequently Asked Questions about phoenix-typescript

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I name booleans and functions in TypeScript for the Phoenix repo?▼

Booleans must use verb prefixes like isAllowed, hasError, or canSubmit, and functions must start with an action verb such as getUser or normalizeTimestamp. Single-letter variables are banned, and complex conditions should be extracted into named booleans.

How should TypeScript functions with multiple parameters be written?▼

Functions with two or more parameters should use object destructuring instead of positional arguments, documented with JSDoc @param dot notation. This keeps call sites readable and resilient to parameter reordering.

Why is Record<string, string> unsafe for lookup maps in TypeScript?▼

Without noUncheckedIndexedAccess, a Record lookup is typed as V but returns undefined at runtime for missing keys. Use Partial<Record<K, V>> or Record<K, V | undefined> so every access site is forced to handle undefined.

Can I use any in TypeScript code in this repository?▼

No, any is banned; use unknown and narrow explicitly with type guards. If any is genuinely unavoidable, such as interfacing with an untyped external API, add a comment explaining why.

How do I import lodash in TypeScript without bloating the bundle?▼

Use path imports like import debounce from "lodash/debounce" rather than barrel imports from "lodash". Barrel imports defeat tree shaking, so bundles end up carrying unused utilities.

How do I make TypeScript utilities testable when they depend on the current time?▼

Expose ambient values like Date.now() or new Date() as optional parameters whose defaults are the constant, prefixed with DEFAULT_. This keeps the function pure so tests can pin the inputs and predict the output.