format-migration: Скилл для форматирования SQL-кода

--- name: format-migration description: Format TypeORM migrations with beautifully formatted SQL code. Use this skill after generating migrations to ensure consistent SQL formatting. --- # TypeORM Migration Formatter You are an expert in TypeORM and PostgreSQL 18. You will format TypeORM migrations to be beautifully formatted SQL code. ## Formatting Rules ### 1. Always Provide Full Migration Code Present the entire `MigrationInterface` class, not just snippets. This helps maintain context and prevents errors. ### 2. Explicitly State Changes Clearly mention any new columns, constraints, indexes, or other SQL features you're adding or modifying. ### 3. SQL Formatting Style All SQL within `queryRunner.query()` must be multi-line, wrapped in `/* sql */` `` blocks, with `/* sql */` on the same line as `await queryRunner.query`: ```typescript await queryRunner.query(/* sql */ ` CREATE TABLE "example" ( "id" uuid PRIMARY KEY DEFAULT uuid_generate_v4(), "name" text NOT NULL ) `); ``` ### 4. ALTER TABLE Formatting Use consistent indentation for `ALTER TABLE` clauses: ```typescript await queryRunner.query(/* sql */ ` ALTER TABLE "table_name" ALTER COLUMN "column_name" SET DEFAULT 'value' `); ``` ### 5. Foreign Key Constraints in CREATE TABLE Split across multiple lines: ```typescript await queryRunner.query(/* sql */ ` CREATE TABLE "example" ( "id" uuid PRIMARY KEY DEFAULT uuid_generate_v4(), "otherId" uuid NOT NULL, CONSTRAINT "FK_example_other" FOREIGN KEY ("otherId") REFERENCES "other_table"("id") ON DELETE CASCADE ON UPDATE NO ACTION ) `); ``` ### 6. Index Handling - `CREATE INDEX` in `up` should always include `IF NOT EXISTS` - `DROP INDEX` in `down` should always include `IF EXISTS` ```typescript // up await queryRunner.query(/* sql */ ` CREATE INDEX IF NOT EXISTS "IDX_example_column" ON "example" ("column") `); // down await queryRunner.query(/* sql */ ` DROP INDEX IF EXISTS "IDX_example_column" `); ``` ### 7. Atomic CREATE TABLE Define all possible constraints (Primary Key, Unique, Foreign Key) directly within the `CREATE TABLE` statement itself. Do not use `ALTER TABLE ADD CONSTRAINT` for foreign keys that can be defined inline during `CREATE TABLE`. ### 8. Concise down Migrations - When constraints (PK, FK) are defined within `CREATE TABLE`, they will be implicitly dropped with the table. Do not include explicit `DROP CONSTRAINT` for them in `down`. - Indexes created on the same table are also implicitly dropped when the table is dropped. Do not include explicit `DROP INDEX` in `down` for table-bound indexes. - If an index is created on a column that is subsequently dropped, that index is implicitly dropped with the column. - The `down` migration for a `CREATE TABLE` should typically just be `DROP TABLE`. - If you're dropping and re-adding columns, ensure corresponding `COMMENT ON COLUMN ... IS NULL` is in `down` if a comment was added in `up`. ### 9. Single Query Per Statement Each `queryRunner.query()` call should only execute a single SQL query. ### 10. No Comments You will not add any comments to the code. Any existing comments will be left there. ## Example Migration ```typescript import type { MigrationInterface, QueryRunner } from 'typeorm'; export class CreateUserProfile1234567890123 implements MigrationInterface { name = 'CreateUserProfile1234567890123'; public async up(queryRunner: QueryRunner): Promise<void> { await queryRunner.query(/* sql */ ` CREATE TABLE "user_profile" ( "id" uuid PRIMARY KEY DEFAULT uuid_generate_v4(), "userId" text NOT NULL, "bio" text, "avatarUrl" text, "createdAt" timestamp NOT NULL DEFAULT now(), "updatedAt" timestamp NOT NULL DEFAULT now(), CONSTRAINT "FK_user_profile_user" FOREIGN KEY ("userId") REFERENCES "user"("id") ON DELETE CASCADE ON UPDATE NO ACTION ) `); await queryRunner.query(/* sql */ ` CREATE INDEX IF NOT EXISTS "IDX_user_profile_userId" ON "user_profile" ("userId") `); } public async down(queryRunner: QueryRunner): Promise<void> { await queryRunner.query(/* sql */ ` DROP TABLE "user_profile" `); } } ``` ## Best Practice Suggestions When reviewing migrations, point out opportunities to improve: - Generic PK names (e.g., `PK_tablename` instead of auto-generated names) - Nullable foreign keys where appropriate - Missing indexes on frequently queried columns - Proper use of `ON DELETE` behavior ## Instructions When the user asks you to format a migration: 1. Read the migration file 2. Apply all formatting rules above 3. Present the complete formatted migration 4. If there are best practice improvements, mention them as suggestions 5. Keep replies short unless explanations are needed When migrations are generated via `pnpm run db:migrate:make`: 1. The auto-lint hook will run ESLint 2. Use this skill to format the SQL for readability 3. Review for schema drift (unrelated changes from local DB differences)