Phoenix typescript-tooling-migration
Migrate or upgrade TypeScript tooling in the Phoenix monorepo. Use when upgrading TypeScript versions, switching tools (ESLint to oxlint, Prettier to oxfmt), upgrading bundlers (Vite, esbuild), or making major dependency upgrades. Triggers on requests to migrate, upgrade, or replace TypeScript/JavaScript tooling.
git clone https://github.com/Arize-ai/phoenix
T=$(mktemp -d) && git clone --depth=1 https://github.com/Arize-ai/phoenix "$T" && mkdir -p ~/.claude/skills && cp -r "$T/.agents/skills/typescript-tooling-migration" ~/.claude/skills/arize-ai-phoenix-typescript-tooling-migration && rm -rf "$T"
.agents/skills/typescript-tooling-migration/SKILL.mdTypeScript Tooling Migration
Guide for migrating or upgrading TypeScript tooling in the Phoenix monorepo. This skill covers upgrading core dependencies (TypeScript, React), switching tools (linters, formatters, bundlers), and managing breaking changes across
app/ and js/ directories.
Monorepo Structure
Phoenix has two TypeScript project directories that must stay in sync:
| Directory | Purpose | Package Manager |
|---|---|---|
| React/TypeScript frontend (main Phoenix UI) | pnpm |
| TypeScript packages monorepo (phoenix-client, phoenix-evals, etc.) | pnpm (workspace) |
Shared Dependencies
Both directories should use the same versions of shared tooling:
| Tool | Sync Enforced | Config Location |
|---|---|---|
| pnpm | CI check | → |
| TypeScript | CI check | → |
| oxlint | CI check | → |
| oxfmt | CI check | → |
Config File Locations
| Config | Location | Purpose |
|---|---|---|
| Root + + | Linter config (nested inheritance) |
| Root | Formatter config (shared) |
| and packages | TypeScript config |
| | Build/dev server config |
| | GraphQL/Relay config |
Migration Types
Type 1: Tool Replacement (e.g., ESLint → oxlint)
Complete replacement of one tool with another.
Workflow:
- Research new tool's migration guide
- Install new tool alongside old
- Create new config, verify it works
- Update package scripts
- Update pre-commit hooks
- Remove old tool and config
- Update documentation
Type 2: Major Version Upgrade (e.g., TypeScript 5 → 6)
Upgrading a tool to a new major version with breaking changes.
Workflow:
- Read changelog/migration guide for breaking changes
- Check compatibility of dependent packages
- Upgrade in a branch, fix breaking changes
- Run full test suite
- Update any deprecated config options
- Update documentation if APIs changed
Type 3: Dependency Upgrade (e.g., React 18 → 19)
Upgrading a core dependency that affects application code.
Workflow:
- Check compatibility matrix (React + React DOM + types)
- Review breaking changes and new features
- Upgrade dependencies together
- Fix breaking changes in application code
- Update any deprecated patterns
- Run E2E tests to verify functionality
Migration Workflow
Phase 1: Research and Planning
- Read official migration guides - Most tools publish upgrade guides
- Check GitHub issues - Look for known migration problems
- Identify scope:
- Which directories affected (
,app/
, or both)js/ - What config files need changes
- What dependencies to add/remove/upgrade
- What code changes are required
- Which directories affected (
- Review current configs - Understand existing setup before changing
- Check dependent packages - Ensure compatibility across the dependency tree
Phase 2: Create a Migration Branch
git checkout -b chore/migrate-<tool>-to-<version> # or git checkout -b chore/upgrade-<tool>-<version>
Phase 3: Install/Upgrade Dependencies
# For app/ (standard project) cd app && pnpm add -D <package>@<version> # For js/ (workspace root) cd js && pnpm add -D -w <package>@<version> # For upgrading existing dependencies cd app && pnpm update <package>@<version>
Tip: Keep old tool installed until migration is verified for tool replacements.
Phase 4: Update Configuration
For tool replacements - create new config:
Phoenix uses nested configs with inheritance where possible:
phoenix/ ├── .<tool>rc.json # Shared base config ├── app/ │ └── .<tool>rc.json # Extends base, adds React-specific options └── js/ └── .<tool>rc.json # Extends base, adds Node-specific options
Config inheritance pattern:
{ "$schema": "./node_modules/<tool>/configuration_schema.json", "extends": ["../.<tool>rc.json"] }
For version upgrades - update existing config:
- Check for deprecated options in the changelog
- Update or remove deprecated settings
- Add any new required settings
Phase 5: Fix Breaking Changes
Code changes:
- Fix type errors from stricter checks
- Update deprecated API usage
- Adapt to new syntax requirements
Config changes:
- Update deprecated config options
- Adjust for changed defaults
Tip: Use the tool's own CLI to identify issues:
pnpm run typecheck # TypeScript errors pnpm run lint # Linter errors pnpm run build # Build errors
Phase 6: Update Package Scripts
Update both
app/package.json and js/package.json if script invocations changed:
{ "scripts": { "lint": "<new-command>", "typecheck": "<new-command>" } }
Phase 7: Update Pre-commit Hooks
Edit
.pre-commit-config.yaml if the tool is used in pre-commit:
- Remove old tool's hook (for replacements)
- Update or add new hook:
- id: <tool>-app name: <tool> (app) entry: pnpm --dir app run <script> language: system files: ^app/.*\.[jt]sx?$ pass_filenames: false - id: <tool>-js name: <tool> (js) entry: pnpm --dir js run <script> language: system files: ^js/.*\.[jt]sx?$ pass_filenames: false
Phase 8: Update Editor Settings
- Update
if extensions changed.vscode/extensions.json - Document any path/binary settings in
:DEVELOPMENT.md
{ "<extension>.path.<binary>": "app/node_modules/<package>/bin/<binary>" }
Note:
.vscode/settings.json is gitignored - document settings in DEVELOPMENT.md.
Phase 9: Remove Old Tool (for replacements)
# Remove old dependencies cd app && pnpm remove <old-tool> <old-plugins> cd js && pnpm remove -w <old-tool> <old-plugins> # Delete old config files rm app/<old-config> js/<old-config>
Phase 10: Test and Verify
# Type checking cd app && pnpm run typecheck cd js && pnpm run typecheck # Linting cd app && pnpm run lint cd js && pnpm run lint # Formatting cd app && pnpm run fmt:check cd js && pnpm run fmt:check # Unit tests cd app && pnpm test cd js && pnpm run -r test # Build cd app && pnpm run build cd js && pnpm run -r build # E2E tests (for significant changes) cd app && pnpm run test:e2e # Pre-commit hooks pre-commit run --all-files
Phase 11: Update Documentation
Files to check and update:
| File | What to update |
|---|---|
| Tool versions, commands, style conventions |
| Setup instructions, VS Code settings |
| Tool references, test commands |
| Commands, workflow instructions |
| PostToolUse hooks |
| Note significant tooling changes |
Phase 12: Add/Update Version Sync Check
For shared dependencies, ensure
.github/workflows/package-version-check.yml enforces consistency:
- name: Check <tool> version consistency run: | APP_VERSION=$(jq -r '.devDependencies.<tool> // empty' app/package.json) JS_VERSION=$(jq -r '.devDependencies.<tool> // empty' js/package.json) echo "app/package.json: <tool>@$APP_VERSION" echo "js/package.json: <tool>@$JS_VERSION" if [ -z "$APP_VERSION" ]; then echo "::error::app/package.json is missing <tool> in devDependencies" exit 1 fi if [ -z "$JS_VERSION" ]; then echo "::error::js/package.json is missing <tool> in devDependencies" exit 1 fi if [ "$APP_VERSION" != "$JS_VERSION" ]; then echo "::error::<tool> versions do not match!" exit 1 fi echo "<tool> versions are consistent: $APP_VERSION"
Key Principles
Keep Directories in Sync
When upgrading shared tooling, always upgrade both
app/ and js/ together. Version drift causes subtle bugs and CI failures.
Performance Matters
- Measure before/after for build times, lint times, test times
- Some compatibility layers (like JS plugins for linters) add significant overhead
- Prefer native implementations over compatibility shims
Backwards Compatibility
- Many tools support legacy config formats (e.g., oxlint supports
comments)eslint-disable - Don't mass-update working code unless there's a clear benefit
- Deprecation warnings are informational - fix them but don't block on them
Config Location Strategy
| Scenario | Approach |
|---|---|
| Identical config for both dirs | Single root config |
| Shared base + dir-specific overrides | Root config + nested configs with |
| Completely different configs per dir | Separate configs (no inheritance) |
Out of Scope Directories
These directories have their own tooling and should NOT be included in migrations:
- Separate OIDC test serverscripts/docker/devops/oidc-server/
- Separate mock serverscripts/mock-llm-server/
- Internal documentation utilitiesinternal_docs/
Troubleshooting
TypeScript Upgrade Issues
Stricter type checking: New TypeScript versions often add stricter checks. Fix errors by:
- Adding explicit type annotations
- Using type assertions where appropriate
- Updating
to temporarily relax checks if neededtsconfig.json
Dependency type mismatches: Ensure
@types/* packages are compatible with the new TS version.
Build Failures After Upgrade
- Clear caches:
rm -rf node_modules/.cache app/dist js/**/dist - Reinstall:
pnpm install - Rebuild:
pnpm run build
Config Not Found
- Check
path is relative to the config file location$schema - For nested configs, verify
path (e.g.,extends
)"../.toolrc.json"
Editor Not Using Updated Tool
- Ensure extension is up to date
- Set explicit binary path in VS Code settings
- Reload VS Code window (
→ "Reload Window")Cmd+Shift+P
Pre-commit Hook Fails
- Run
in both directoriespnpm install - Verify script name in
matches hook entrypackage.json - Test script manually:
pnpm --dir app run <script>
CI Fails But Local Passes
- Check Node version matches CI (see
).nvmrc - Ensure lockfile is committed (
)pnpm-lock.yaml - Run with
locally to match CI behavior--frozen-lockfile
CI Workflows
Relevant CI files for TypeScript tooling:
| Workflow | Purpose |
|---|---|
| app/ typecheck, lint, test |
| js/ build, test, lint |
| Version sync enforcement |
| E2E tests |