{"slug":"mkosir-typescript-naming","name":"typescript-naming","description":"Apply, review, and explain TypeScript naming conventions. Use automatically for tasks involving exports, identifiers, generic type parameters, acronyms, React props and handlers, hooks, comments, or TSDoc.","long_description":"---\nname: typescript-naming\ndescription: Apply, review, and explain TypeScript naming conventions. Use automatically for tasks involving exports, identifiers, generic type parameters, acronyms, React props and handlers, hooks, comments, or TSDoc.\n---\n\n# Naming\n\nApply the TypeScript Style Guide's naming conventions in the context of the current task.\n\n## Workflow\n\n1. Inspect the consuming repository's conventions and configuration.\n2. Let explicit repository conventions take precedence over this opinionated guidance.\n3. Apply, review, or explain only the guidance relevant to the task.\n4. State important tradeoffs when the appropriate name or documentation depends on context or judgment.\n\n## Boundaries\n\n- Keep ESLint and other tooling responsible for checks they can enforce automatically.\n- Do not introduce unrelated TypeScript Style Guide conventions merely because this skill is active.\n\n## Related Guidance\n\n### Type-Safe Constants With Satisfies\n\nFor detailed guidance on validating constants against existing types, use `typescript-types` when it is available.\n\n\n\n## Naming\n\nStrive to keep naming conventions consistent and readable, with important context provided, because another person will maintain the code you have written.\n\n### Named Export\n\n\n{`export default [\n {\n rules: { 'import/no-default-export': 'error' },\n },\n // In case of exceptions disable the rule\n {\n files: ['src/pages/**/*'],\n rules: { 'import/no-default-export': 'off' },\n },\n];\n`}\n\n\nThis keeps variable and function names consistent across the entire codebase. Named exports have the benefit of\nerroring when import statements try to import something that hasn't been declared.\n\n### Naming Conventions\n\nWhile it's often hard to find the best name, aim to optimize code for consistency and future readers by following these conventions:\n\n#### Variables {#variables-1}\n\n- **Locals** \n Camel case \n `products`, `productsFiltered`\n- **Booleans** \n Prefixed with `is`, `has` etc. \n `isDisabled`, `hasProduct`\n \n \n {`'@typescript-eslint/naming-convention': [\n 'error',\n {\n selector: 'variable',\n types: ['boolean'],\n format: ['PascalCase'],\n prefix: ['is', 'are', 'should', 'has', 'can', 'did', 'will'],\n }\n ]\n `}\n \n \n\n- **Constants** \n Capitalized\n\n ```ts\n const FEATURED_PRODUCT_ID = '8f47d2a1-b13e-4d5a-a7d8-6ef1234';\n ```\n\n- **Object & Array Constants**\n\n Singular, capitalized with const assertion.\n\n ```ts\n const IDLE_ORDER = {\n pending: 'idle',\n fulfilled: true,\n error: 'Shipping Error',\n } as const;\n\n const DASHBOARD_ACCESS_ROLES = ['admin', 'editor', 'moderator'] as const;\n ```\n\n If a type exists, use [Type-Safe Constants With Satisfies](#type-safe-constants-with-satisfies).\n\n ```ts\n // Type OrderStatus is predefined (e.g. generated from database schema, API)\n type OrderStatus = {\n pending: 'pending' | 'idle';\n fulfilled: boolean;\n error: string;\n };\n\n const IDLE_ORDER = {\n pending: 'idle',\n fulfilled: true,\n error: 'Shipping Error',\n } as const satisfies OrderStatus;\n\n // Type UserRole is predefined\n type UserRole = 'admin' | 'editor' | 'moderator' | 'viewer' | 'guest';\n\n const DASHBOARD_ACCESS_ROLES = ['admin', 'editor', 'moderator'] as const satisfies ReadonlyArray;\n ```\n\n#### Functions {#functions-1}\n\nCamel case \n`filterProductsByType`, `formatCurrency`\n\n#### Types {#types-1}\n\nPascal case \n`OrderStatus`, `ProductItem`\n\n\n {`\n'@typescript-eslint/naming-convention': [\n 'error',\n {\n selector: 'typeAlias',\n format: ['PascalCase'],\n },\n]`}\n\n\n#### Generics\n\nA generic type parameter must start with the capital letter T followed by a descriptive name `TRequest`, `TFooBar`.\n\nKey reasons and benefits:\n\n- Complex types often involve generics, for which clear naming improves readability and maintainability.\n- Single-letter generics like `T`, `K`, and `U` are disallowed. The more parameters we introduce, the easier it is to mistake them.\n- Prefixing with `T` makes it immediately obvious that it's a generic type parameter, not a regular type.\n- A common scenario is when a generic parameter shadows an existing type because it has the same name, e.g. ``.\n\n\n {`'@typescript-eslint/naming-convention': [\n 'error',\n {\n // Generic type parameter must start with letter T, followed by any uppercase letter.\n selector: 'typeParameter',\n format: ['PascalCase'],\n custom: { regex: '^T[A-Z]', match: true },\n }\n]`}\n\n\n```ts\n// ❌ Avoid naming generic parameters with one letter\nconst createPair = (first: T, second: K): [T, K] => {\n return [first, second];\n};\nconst pair = createPair(1, 'a');\n\n// ✅ Use descriptive names starting with capital T\nconst createPair = (first: TFirst, second: TSecond): [TFirst, TSecond] => {\n return [first, second];\n};\nconst pair = createPair(1, 'a');\n\n// ❌ Avoid naming generic parameters without a prefix - which 'Request' is which?\nconst handle = (req: Request): void => {...\n\n// ✅ Prefix generic parameter with capital T\nconst handle = (req: TRequest): void => {...\n```\n\n#### Abbreviations & Acronyms\n\nTreat acronyms as whole words, with capitalized first letter only.\n\n```ts\n// ❌ Avoid\nconst FAQList = ['qa-1', 'qa-2'];\nconst generateUserURL(params) => {...}\n\n// ✅ Use\nconst FaqList = ['qa-1', 'qa-2'];\nconst generateUserUrl(params) => {...}\n```\n\nFor readability, strive to avoid abbreviations, unless they are widely accepted and necessary.\n\n```ts\n// ❌ Avoid\nconst GetWin(params) => {...}\n\n// ✅ Use\nconst GetWindow(params) => {...}\n```\n\n#### React Components\n\nPascal case \n `ProductItem`, `ProductsPage`\n\n#### Prop Types\n\nReact component name followed by the \"Props\" suffix \n `[ComponentName]Props` - `ProductItemProps`, `ProductsPageProps`\n\n#### Callback Props\n\nEvent handler (callback) props are prefixed with `on*` - e.g. `onClick`. \nEvent handler implementation functions are prefixed with `handle*` - e.g. `handleClick`.\n\n{`'react/jsx-handler-names': [\n 'error',\n {\n eventHandlerPrefix: 'handle',\n eventHandlerPropPrefix: 'on',\n },\n]`}\n\n```tsx\n// ❌ Avoid inconsistent callback prop naming\n