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.