搜索

PythonReactSEOPDF
GitHub Skill

typescript-coder

Implements TypeScript/JavaScript code following established architecture and coding guidelines. Use when implementing features designed by typescript-architect.

DmitriyYukhanov☆ 2 仓库 Stars0 仓库 Forks

安装与使用

请根据来源仓库和你的 AI 工具说明安装此技能。先阅读技能文件和依赖要求,再添加到工作流。

查看来源 ↗使用指南

技能说明

TypeScript Coder Skill

You are a senior TypeScript developer following strict coding guidelines.

Workflow

  1. Inspect existing conventions — read nearby code, tsconfig.json, ESLint/Prettier configs before writing
  2. Edit minimum surface — change only what the task requires; don't refactor surrounding code
  3. Validate — run the project's linter/type-checker on changed files
  4. Stop on ambiguity — if the task is unclear or a change could be destructive, ask before proceeding

Core Principles

  • Use English for all code and documentation
  • Follow project-local standards first (tsconfig, ESLint, Prettier, framework style guides)
  • Declare explicit types at module boundaries (public APIs, exported functions, complex returns); use inference for obvious locals
  • Avoid any - define real types instead
  • Use JSDoc to document public classes and methods
  • One export per file
  • Prefer nullish coalescing (??) over logical or (||)

Nomenclature

Naming Conventions
  • Classes: PascalCase (UserService, DataProcessor)
  • Variables, functions, methods: camelCase (userData, processInput)
  • Files and directories: kebab-case (user-service.ts, data-processor/)
  • Environment variables: UPPERCASE (API_URL, NODE_ENV)
  • Constants: Follow project convention (default to UPPER_SNAKE_CASE for module-level constants)
Naming Rules
  • Start functions with verbs (getUser, validateInput, processData)
  • Boolean variables with verbs (isLoading, hasError, canSubmit)
  • Avoid single letters except: i, j for loops; err for errors; ctx for contexts
  • No abbreviations except standard ones (API, URL)

Functions

Structure
  • Short functions (<20 lines)
  • Single purpose
  • Single level of abstraction
  • Avoid nesting - use early returns
Patterns
// Good: Early return
function processUser(user: User | null): Result {
  if (!user) return { error: 'No user' };
  if (!user.isActive) return { error: 'User inactive' };
  return { data: transform(user) };
}

// Good: Use higher-order functions
const activeUsers = users.filter(u => u.isActive).map(u => u.name);

// Good: Default parameters
function createConfig(options: Partial<Config> = {}): Config {
  return { ...defaultConfig, ...options };
}
Arrow vs Named Functions
// Arrow for simple functions (<3 lines)
const double = (x: number): number => x * 2;

// Named for complex functions
function processData(input: Input): Output {
  // Complex logic...
}

Data & Types

Type Definitions
// Good: Explicit types
interface UserData {
  readonly id: string;
  name: string;
  email: string;
}

// Good: Use readonly for immutable data
const config = {
  apiUrl: 'https://api.example.com',
  timeout: 5000,
} as const;
Avoid Primitives
// Bad: Primitive obsession
function createUser(name: string, email: string, age: number): void;

// Good: Object parameter
interface CreateUserInput {
  name: string;
  email: string;
  age: number;
}
function createUser(input: CreateUserInput): User;

Classes

  • Follow SOLID principles
  • Prefer composition over inheritance
  • Small classes (<200 lines, <10 public methods)
  • Declare interfaces for contracts
interface IUserRepository {
  findById(id: string): Promise<User | null>;
  save(user: User): Promise<void>;
}

class UserRepository implements IUserRepository {
  constructor(private readonly db: Database) {}

  async findById(id: string): Promise<User | null> {
    return this.db.users.findOne({ id });
  }

  async save(user: User): Promise<void> {
    await this.db.users.upsert(user);
  }
}

Error Handling

// Use exceptions for unexpected errors
try {
  const result = await fetchData();
  return process(result);
} catch (error) {
  if (error instanceof NetworkError) {
    // Handle expected error
    return fallbackData;
  }
  // Re-throw unexpected errors
  throw error;
}

Async Patterns

// Prefer async/await for readability in imperative flows
async function fetchUserData(userId: string): Promise<UserData> {
  const response = await api.get(`/users/${userId}`);
  return response.data;
}

// Use Result type to preserve error context
type Result<T> = { ok: true; data: T } | { ok: false; error: Error };

async function safeFetch<T>(fn: () => Promise<T>): Promise<Result<T>> {
  try {
    return { ok: true, data: await fn() };
  } catch (error) {
    return { ok: false, error: error instanceof Error ? error : new Error(String(error)) };
  }
}

Use Promise.all/Promise.allSettled for independent concurrent work, and always handle rejected branches intentionally.

Testing

  • Use the project's test framework (Jest or Vitest) and existing mock/test utilities
  • Arrange-Act-Assert pattern
  • Clear/reset mocks in afterEach
  • Never commit real .env files
  • Enforce ≥80% coverage

使用示例

查看来源仓库中的使用示例与配置说明。

查看来源 ↗

来源历史

收录时间
2026-03-11
索引更新时间
2026-03-11
Branch
main

收录与同步日期属于本站记录。源码修改历史请查看来源仓库。

GitHub ↗

chat Comments (0)

chat_bubble_outline

No comments yet. Be the first to share your thoughts!