{"owner":"microsoft","repo":"TypeScript","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md","CLAUDE.md",".github/copilot-instructions.md"],"skills":{"AGENTS.md":"# 🚨 CRITICAL: This Repository Is in Maintenance Mode 🚨\n\n**You MUST read and follow these instructions before taking any coding action in this repository.**\n\nThis repository (`microsoft/TypeScript`) is the JavaScript-based TypeScript compiler and is **effectively closed for general development**. TypeScript 6.0 is the **last JavaScript-based release**. Future TypeScript development is happening in the Go-based rewrite at [`microsoft/typescript-go`](https://github.com/microsoft/typescript-go).\n\nSee [issue #62963](https://github.com/microsoft/TypeScript/issues/62963) and the [TypeScript 7.0 progress blog post](https://devblogs.microsoft.com/typescript/progress-on-typescript-7-december-2025/) for full details.\n\n## ❌ DO NOT create coding PRs for this repository\n\n**Unless the user explicitly acknowledges the above and confirms their change falls into one of these narrow accepted categories:**\n\n- Crashes introduced in 5.9 or 6.0 that **also repro in 7.0** and have a portable fix without behavioral changes\n- Security issues\n- Language service crashes that substantially impact mainline usage\n- Serious regressions from 5.9 that impact a large proportion of users\n- Non-disruptive `lib.d.ts` changes\n\n## Required behavior for coding agents\n\nIf asked to make code changes or create a PR in this repository, you **MUST**:\n\n1. Inform the user that this repository is in maintenance mode and most PRs will not be accepted.\n2. Ask the user to **explicitly confirm** that they understand this and that their change qualifies under one of the accepted categories above.\n3. **Refuse to proceed** until that acknowledgement is given.\n4. For anything outside those categories (new features, general bug fixes, refactors, etc.), direct the user to [`microsoft/typescript-go`](https://github.com/microsoft/typescript-go) instead.\n\n---\n\nFor detailed build instructions, test writing guides, and workflow recommendations, see [`.github/copilot-instructions.md`](.github/copilot-instructions.md).\n","CLAUDE.md":"Read AGENTS.md before proceeding.",".github/copilot-instructions.md":"# 🚨 CRITICAL: This Repository Is in Maintenance Mode 🚨\n\n**You MUST read and follow these instructions before taking any coding action in this repository.**\n\nThis repository (`microsoft/TypeScript`) is the JavaScript-based TypeScript compiler and is **effectively closed for general development**. TypeScript 6.0 is the **last JavaScript-based release**. Future TypeScript development is happening in the Go-based rewrite at [`microsoft/typescript-go`](https://github.com/microsoft/typescript-go).\n\nSee [issue #62963](https://github.com/microsoft/TypeScript/issues/62963) and the [TypeScript 7.0 progress blog post](https://devblogs.microsoft.com/typescript/progress-on-typescript-7-december-2025/) for full details.\n\n## ❌ DO NOT create coding PRs for this repository\n\n**Unless the user explicitly acknowledges the above and confirms their change falls into one of these narrow accepted categories:**\n\n- Crashes introduced in 5.9 or 6.0 that **also repro in 7.0** and have a portable fix without behavioral changes\n- Security issues\n- Language service crashes that substantially impact mainline usage\n- Serious regressions from 5.9 that impact a large proportion of users\n- Non-disruptive `lib.d.ts` changes\n\n## Required behavior for coding agents\n\nIf asked to make code changes or create a PR in this repository, you **MUST**:\n\n1. Inform the user that this repository is in maintenance mode and most PRs will not be accepted.\n2. Ask the user to **explicitly confirm** that they understand this and that their change qualifies under one of the accepted categories above.\n3. **Refuse to proceed** until that acknowledgement is given.\n4. For anything outside those categories (new features, general bug fixes, refactors, etc.), direct the user to [`microsoft/typescript-go`](https://github.com/microsoft/typescript-go) instead.\n\n---\n\n# Guide for Copilot\n\nThis document provides a concise guide for writing TypeScript fourslash tests and compiler tests, along with build instructions.\n\n## Build Instructions Summary\n\n### Setup\n1. Install Node.js (current or LTS)\n2. Clone the repository: `git clone --depth=1 https://github.com/microsoft/TypeScript`\n3. Install dependencies: `npm ci`\n\n### Common Build Tasks\n```bash\nnpx hereby local             # Build the compiler into built/local\nnpx hereby clean             # Delete the built compiler  \nnpx hereby tests             # Build the test infrastructure\nnpx hereby runtests          # Run all tests\nnpx hereby runtests-parallel # Run tests in parallel 🚨 MANDATORY BEFORE FINISHING!\nnpx hereby runtests --runner=fourslash # Run only fourslash tests\nnpx hereby runtests --runner=compiler # Run only compiler tests\nnpx hereby runtests --tests=<testPath> # Run specific test\nnpx hereby baseline-accept   # Accept new test baselines\nnpx hereby lint              # Run eslint 🚨 MANDATORY BEFORE FINISHING!\nnpx hereby format            # Run code formatting 🚨 MANDATORY BEFORE FINISHING!\n```\n\n## Fourslash Test Syntax Guide\n\nFourslash tests are interactive TypeScript language service tests. They validate IDE features like completions, quick info, navigation, and refactoring.\n\n### Basic Structure\n```typescript\n/// <reference path='fourslash.ts'/>\n\n////code goes here with /*markers*/\n\n// Test assertions go here\n```\n\n### Key Syntax Elements\n\n#### 1. Source Code Definition\nUse `////` to define source code lines:\n```typescript\n////function foo(x: number) {\n////    return x + 1;\n////}\n////let result = foo(/*marker*/42);\n```\n\n#### 2. Markers for Positioning\nUse `/**/` for anonymous markers or `/*name*/` for named markers:\n```typescript\n////let x = /*1*/someValue;\n////let y = /*cursor*/anotherValue;\n```\n\n#### 3. Multi-file Tests\nUse `// @Filename:` to define multiple files:\n```typescript\n// @Filename: /a.ts\n////export const value = 42;\n\n// @Filename: /b.ts  \n////import { value } from './a';\n////console.log(/*marker*/value);\n```\n\n#### 4. Ranges\nUse `[|text|]` to define text ranges:\n```typescript\n////function test() {\n////    [|return 42;|]\n////}\n```\n\n### Common API Patterns\n\n#### Navigation & Positioning\n```typescript\ngoTo.marker(\"markerName\");         // Navigate to marker\ngoTo.marker();                     // Navigate to anonymous marker /**/\n```\n\n#### Verification (Prefer these over baselines)\n```typescript\nverify.currentLineContentIs(\"expected content\");\nverify.completions({ includes: \"itemName\" });\nverify.completions({ excludes: \"itemName\" });\nverify.quickInfoIs(\"expected info\");\nverify.codeFix({\n    description: \"Fix description\",\n    newFileContent: \"expected content after fix\"\n});\n```\n\n#### Completions Testing\n```typescript\nverify.completions({ \n    marker: \"1\",\n    includes: { name: \"foo\", source: \"/a\", hasAction: true },\n    isNewIdentifierLocation: true,\n    preferences: { includeCompletionsForModuleExports: true }\n});\n```\n\n#### Code Fixes Testing\n```typescript\nverify.codeFix({\n    description: \"Add missing property\",\n    index: 0,\n    newFileContent: `class C {\n    property: string;\n    method() { this.property = \"value\"; }\n}`\n});\n```\n\n#### Formatting\n```typescript\nformat.document();\nverify.currentLineContentIs(\"formatted content\");\n```\n\n### Simple Example\n```typescript\n/// <reference path='fourslash.ts'/>\n\n////interface User {\n////    name: string;\n////}\n////\n////const user: User = {\n////    /*completion*/\n////};\n\nverify.completions({\n    marker: \"completion\",\n    includes: { name: \"name\", sortText: \"0\" }\n});\n```\n\n## Compiler Test Syntax Guide\n\nCompiler tests validate TypeScript compilation behavior, type checking, and error reporting.\n\n### Basic Structure\n- Simple `.ts` files in `tests/cases/compiler/`\n- Use comments to indicate expected behavior\n- No special test harness - just TypeScript code\n\n### Compiler Directives\nUse `// @directive: value` for compiler options:\n```typescript\n// @strict: true\n// @target: ES2015\n// @lib: ES2015,DOM\n\nlet x: string = 42; // Error expected\n```\n\n### Common Directives\n```typescript\n// @strict: true/false\n// @noImplicitAny: true/false  \n// @target: ES5/ES2015/ES2020/ESNext\n// @module: commonjs/amd/es6/esnext\n// @lib: ES5,DOM/ES2015/ES2020\n// @declaration: true/false\n// @skipLibCheck: true/false\n```\n\n### Multi-file Tests\n```typescript\n// @Filename: helper.ts\nexport function helper(x: number): string {\n    return x.toString();\n}\n\n// @Filename: main.ts  \nimport { helper } from \"./helper\";\nconst result = helper(42);\n```\n\n### Error Expectations\nUse comments to document expected behavior:\n```typescript\nabstract class Base {\n    abstract method(): void;\n}\n\nclass Derived extends Base {\n    // Missing implementation - should error\n}\n\nnew Base(); // Should error - cannot instantiate abstract class\n```\n\n### Type Testing Patterns\n```typescript\n// Test type inference\nlet inferred = [1, 2, 3]; // Should infer number[]\n\n// Test type compatibility  \ntype A = { x: number };\ntype B = { x: number; y: string };\nlet a: A = { x: 1 };\nlet b: B = { x: 1, y: \"hello\" };\na = b; // Should work - B is assignable to A\nb = a; // Should error - A missing property y\n```\n\n### Simple Example\n```typescript\n// Test that optional properties work correctly\ninterface Config {\n    required: string;\n    optional?: number;\n}\n\nconst config1: Config = { required: \"test\" }; // Should work\nconst config2: Config = { required: \"test\", optional: 42 }; // Should work  \nconst config3: Config = { optional: 42 }; // Should error - missing required\n```\n\n## Test Writing Best Practices\n\n### For Fourslash Tests\n1. **Prefer validation over baselines** - Use `verify.currentLineContentIs()` instead of `verify.baseline*()`\n2. **Use simple, focused examples** - Test one feature at a time\n3. **Name markers clearly** - Use descriptive marker names like `/*completion*/`\n4. **Test the simplest form first** - Start with basic cases before complex scenarios\n\n### For Compiler Tests  \n1. **Use clear file names** - Name tests after the feature being tested\n2. **Add explanatory comments** - Document expected behavior with comments\n3. **Test error cases** - Include both valid and invalid code examples\n4. **Keep tests focused** - One primary feature per test file\n\n### General Guidelines\n1. **Make tests deterministic** - Avoid random or environment-dependent behavior\n2. **Use realistic examples** - Test scenarios developers actually encounter  \n3. **Start simple** - Begin with the most basic case of a feature\n4. **Test edge cases** - Include boundary conditions and error scenarios\n\n## Running Specific Tests\n\n```bash\n# Run a specific fourslash test\nnpx hereby runtests --tests=tests/cases/fourslash/completionForObjectProperty.ts\n\n# Run a specific compiler test  \nnpx hereby runtests --tests=tests/cases/compiler/abstractClassUnionInstantiation.ts\n\n# Run tests matching a pattern\nnpx hereby runtests --tests=tests/cases/fourslash/completion*.ts\n```\n\n## Important Guidelines\n\n### 🚨 CRITICAL: Before Finishing Your Work 🚨\n\n**THESE STEPS ARE MANDATORY BEFORE COMMITTING/PUSHING ANY CHANGES:**\n\n1. **MUST RUN:** `npx hereby runtests-parallel` (even though it takes 10-15 minutes)\n2. **MUST RUN:** `npx hereby lint` and fix ALL lint issues\n3. **MUST RUN:** `npx hereby format` as the final step\n\n**❌ PRs that fail these checks will be rejected without review.**\n\n### Keeping Things Tidy\n\n- You can assume lint, tests, and formatting are clean on a fresh clone\n- Only run these verification steps AFTER making changes to code\n- Run `npx hereby lint` and fix ALL issues after making changes\n- Run `npx hereby format` as your final step after making changes\n\n### Test Locations\n\n- Only add testcases in `tests/cases/compiler` or `tests/cases/fourslash`\n- Filenames in `tests/cases/compiler` must always end with `.ts`, not `.d.ts`\n- Do not write direct unit tests as they are almost never the correct test format for our repo\n\n### Performance Expectations\n\n- Running a set of tests may take up to 4 minutes\n- A full test run may take up to 15 minutes\n\n### Working with Issues\n\n- Maintainer comments in the issue should generally take priority over OP's comments\n- Maintainers might give you hints on where to start. They are not always right, but a good place to start\n\n### Debugging Tips\n\nprintf debugging is going to be very useful as you are figuring things out.\nTo do this, use `console.log`, but you'll need to `ts-ignore` it.\nWrite something like this:\n```ts,diff\nfunction checkSomething(n: Node) {\n    doSomething(n);\n+   // @ts-ignore DEBUG CODE ONLY, REMOVE ME WHEN DONE\n+   console.log(`Got node with pos = ${n.pos}`);\n    doSomethingElse(n);\n}\n```\nWe have a lot of enums so you might want to print back their symbolic name, to do this, index back into the name of the enum\n```ts\n   // @ts-ignore DEBUG CODE ONLY, REMOVE ME WHEN DONE\n   console.log(`Got node with kind = ${SyntaxKind[n.kind]}`);\n```\n\n## Recommended Workflow\n\nWhen fixing bugs or implementing features, follow this workflow:\n\n1. **Make a testcase that demonstrates the behavior**\n   - Run it (by itself) and review the baselines it generates to ensure it demonstrates the bug\n   - Add the test and its baselines in one commit\n\n2. **Fix the bug by changing code as appropriate**\n   - Put this fix in another commit\n\n3. **Run the test you wrote again**\n   - Ensure the baselines change in a way that demonstrates that the bug is fixed\n   - Put this baseline diff in its own commit\n\n4. **Add more testing**\n   - Once you've got the basics figured out, enhance your test to cover edge cases and other variations\n   - Run the test again and commit the baseline diff along with the test edit\n\n5. **🚨 MANDATORY: Run all other tests to ensure you didn't break anything**\n   - **REQUIRED:** Run `npx hereby runtests-parallel` and wait for it to finish (10-15 minutes is normal!)\n   - **THIS STEP CANNOT BE SKIPPED** - patience is essential!\n   - Some collateral baseline changes are normal, but review for correctness\n   - Put these diffs in another commit\n\n6. **🚨 MANDATORY: Lint and format your changes**\n   - **REQUIRED:** Run `npx hereby lint` and fix ALL issues\n   - **REQUIRED:** Run `npx hereby format` before you're done\n   - **YOU CANNOT FINISH WITHOUT THESE STEPS**\n   - Double-check your line endings. Source files in this repo typically use CRLF line endings. Fix all line endings to be consistent before you wrap up\n"},"files":{"AGENTS.md":"# 🚨 CRITICAL: This Repository Is in Maintenance Mode 🚨\n\n**You MUST read and follow these instructions before taking any coding action in this repository.**\n\nThis repository (`microsoft/TypeScript`) is the JavaScript-based TypeScript compiler and is **effectively closed for general development**. TypeScript 6.0 is the **last JavaScript-based release**. Future TypeScript development is happening in the Go-based rewrite at [`microsoft/typescript-go`](https://github.com/microsoft/typescript-go).\n\nSee [issue #62963](https://github.com/microsoft/TypeScript/issues/62963) and the [TypeScript 7.0 progress blog post](https://devblogs.microsoft.com/typescript/progress-on-typescript-7-december-2025/) for full details.\n\n## ❌ DO NOT create coding PRs for this repository\n\n**Unless the user explicitly acknowledges the above and confirms their change falls into one of these narrow accepted categories:**\n\n- Crashes introduced in 5.9 or 6.0 that **also repro in 7.0** and have a portable fix without behavioral changes\n- Security issues\n- Language service crashes that substantially impact mainline usage\n- Serious regressions from 5.9 that impact a large proportion of users\n- Non-disruptive `lib.d.ts` changes\n\n## Required behavior for coding agents\n\nIf asked to make code changes or create a PR in this repository, you **MUST**:\n\n1. Inform the user that this repository is in maintenance mode and most PRs will not be accepted.\n2. Ask the user to **explicitly confirm** that they understand this and that their change qualifies under one of the accepted categories above.\n3. **Refuse to proceed** until that acknowledgement is given.\n4. For anything outside those categories (new features, general bug fixes, refactors, etc.), direct the user to [`microsoft/typescript-go`](https://github.com/microsoft/typescript-go) instead.\n\n---\n\nFor detailed build instructions, test writing guides, and workflow recommendations, see [`.github/copilot-instructions.md`](.github/copilot-instructions.md).\n","CLAUDE.md":"Read AGENTS.md before proceeding.",".github/copilot-instructions.md":"# 🚨 CRITICAL: This Repository Is in Maintenance Mode 🚨\n\n**You MUST read and follow these instructions before taking any coding action in this repository.**\n\nThis repository (`microsoft/TypeScript`) is the JavaScript-based TypeScript compiler and is **effectively closed for general development**. TypeScript 6.0 is the **last JavaScript-based release**. Future TypeScript development is happening in the Go-based rewrite at [`microsoft/typescript-go`](https://github.com/microsoft/typescript-go).\n\nSee [issue #62963](https://github.com/microsoft/TypeScript/issues/62963) and the [TypeScript 7.0 progress blog post](https://devblogs.microsoft.com/typescript/progress-on-typescript-7-december-2025/) for full details.\n\n## ❌ DO NOT create coding PRs for this repository\n\n**Unless the user explicitly acknowledges the above and confirms their change falls into one of these narrow accepted categories:**\n\n- Crashes introduced in 5.9 or 6.0 that **also repro in 7.0** and have a portable fix without behavioral changes\n- Security issues\n- Language service crashes that substantially impact mainline usage\n- Serious regressions from 5.9 that impact a large proportion of users\n- Non-disruptive `lib.d.ts` changes\n\n## Required behavior for coding agents\n\nIf asked to make code changes or create a PR in this repository, you **MUST**:\n\n1. Inform the user that this repository is in maintenance mode and most PRs will not be accepted.\n2. Ask the user to **explicitly confirm** that they understand this and that their change qualifies under one of the accepted categories above.\n3. **Refuse to proceed** until that acknowledgement is given.\n4. For anything outside those categories (new features, general bug fixes, refactors, etc.), direct the user to [`microsoft/typescript-go`](https://github.com/microsoft/typescript-go) instead.\n\n---\n\n# Guide for Copilot\n\nThis document provides a concise guide for writing TypeScript fourslash tests and compiler tests, along with build instructions.\n\n## Build Instructions Summary\n\n### Setup\n1. Install Node.js (current or LTS)\n2. Clone the repository: `git clone --depth=1 https://github.com/microsoft/TypeScript`\n3. Install dependencies: `npm ci`\n\n### Common Build Tasks\n```bash\nnpx hereby local             # Build the compiler into built/local\nnpx hereby clean             # Delete the built compiler  \nnpx hereby tests             # Build the test infrastructure\nnpx hereby runtests          # Run all tests\nnpx hereby runtests-parallel # Run tests in parallel 🚨 MANDATORY BEFORE FINISHING!\nnpx hereby runtests --runner=fourslash # Run only fourslash tests\nnpx hereby runtests --runner=compiler # Run only compiler tests\nnpx hereby runtests --tests=<testPath> # Run specific test\nnpx hereby baseline-accept   # Accept new test baselines\nnpx hereby lint              # Run eslint 🚨 MANDATORY BEFORE FINISHING!\nnpx hereby format            # Run code formatting 🚨 MANDATORY BEFORE FINISHING!\n```\n\n## Fourslash Test Syntax Guide\n\nFourslash tests are interactive TypeScript language service tests. They validate IDE features like completions, quick info, navigation, and refactoring.\n\n### Basic Structure\n```typescript\n/// <reference path='fourslash.ts'/>\n\n////code goes here with /*markers*/\n\n// Test assertions go here\n```\n\n### Key Syntax Elements\n\n#### 1. Source Code Definition\nUse `////` to define source code lines:\n```typescript\n////function foo(x: number) {\n////    return x + 1;\n////}\n////let result = foo(/*marker*/42);\n```\n\n#### 2. Markers for Positioning\nUse `/**/` for anonymous markers or `/*name*/` for named markers:\n```typescript\n////let x = /*1*/someValue;\n////let y = /*cursor*/anotherValue;\n```\n\n#### 3. Multi-file Tests\nUse `// @Filename:` to define multiple files:\n```typescript\n// @Filename: /a.ts\n////export const value = 42;\n\n// @Filename: /b.ts  \n////import { value } from './a';\n////console.log(/*marker*/value);\n```\n\n#### 4. Ranges\nUse `[|text|]` to define text ranges:\n```typescript\n////function test() {\n////    [|return 42;|]\n////}\n```\n\n### Common API Patterns\n\n#### Navigation & Positioning\n```typescript\ngoTo.marker(\"markerName\");         // Navigate to marker\ngoTo.marker();                     // Navigate to anonymous marker /**/\n```\n\n#### Verification (Prefer these over baselines)\n```typescript\nverify.currentLineContentIs(\"expected content\");\nverify.completions({ includes: \"itemName\" });\nverify.completions({ excludes: \"itemName\" });\nverify.quickInfoIs(\"expected info\");\nverify.codeFix({\n    description: \"Fix description\",\n    newFileContent: \"expected content after fix\"\n});\n```\n\n#### Completions Testing\n```typescript\nverify.completions({ \n    marker: \"1\",\n    includes: { name: \"foo\", source: \"/a\", hasAction: true },\n    isNewIdentifierLocation: true,\n    preferences: { includeCompletionsForModuleExports: true }\n});\n```\n\n#### Code Fixes Testing\n```typescript\nverify.codeFix({\n    description: \"Add missing property\",\n    index: 0,\n    newFileContent: `class C {\n    property: string;\n    method() { this.property = \"value\"; }\n}`\n});\n```\n\n#### Formatting\n```typescript\nformat.document();\nverify.currentLineContentIs(\"formatted content\");\n```\n\n### Simple Example\n```typescript\n/// <reference path='fourslash.ts'/>\n\n////interface User {\n////    name: string;\n////}\n////\n////const user: User = {\n////    /*completion*/\n////};\n\nverify.completions({\n    marker: \"completion\",\n    includes: { name: \"name\", sortText: \"0\" }\n});\n```\n\n## Compiler Test Syntax Guide\n\nCompiler tests validate TypeScript compilation behavior, type checking, and error reporting.\n\n### Basic Structure\n- Simple `.ts` files in `tests/cases/compiler/`\n- Use comments to indicate expected behavior\n- No special test harness - just TypeScript code\n\n### Compiler Directives\nUse `// @directive: value` for compiler options:\n```typescript\n// @strict: true\n// @target: ES2015\n// @lib: ES2015,DOM\n\nlet x: string = 42; // Error expected\n```\n\n### Common Directives\n```typescript\n// @strict: true/false\n// @noImplicitAny: true/false  \n// @target: ES5/ES2015/ES2020/ESNext\n// @module: commonjs/amd/es6/esnext\n// @lib: ES5,DOM/ES2015/ES2020\n// @declaration: true/false\n// @skipLibCheck: true/false\n```\n\n### Multi-file Tests\n```typescript\n// @Filename: helper.ts\nexport function helper(x: number): string {\n    return x.toString();\n}\n\n// @Filename: main.ts  \nimport { helper } from \"./helper\";\nconst result = helper(42);\n```\n\n### Error Expectations\nUse comments to document expected behavior:\n```typescript\nabstract class Base {\n    abstract method(): void;\n}\n\nclass Derived extends Base {\n    // Missing implementation - should error\n}\n\nnew Base(); // Should error - cannot instantiate abstract class\n```\n\n### Type Testing Patterns\n```typescript\n// Test type inference\nlet inferred = [1, 2, 3]; // Should infer number[]\n\n// Test type compatibility  \ntype A = { x: number };\ntype B = { x: number; y: string };\nlet a: A = { x: 1 };\nlet b: B = { x: 1, y: \"hello\" };\na = b; // Should work - B is assignable to A\nb = a; // Should error - A missing property y\n```\n\n### Simple Example\n```typescript\n// Test that optional properties work correctly\ninterface Config {\n    required: string;\n    optional?: number;\n}\n\nconst config1: Config = { required: \"test\" }; // Should work\nconst config2: Config = { required: \"test\", optional: 42 }; // Should work  \nconst config3: Config = { optional: 42 }; // Should error - missing required\n```\n\n## Test Writing Best Practices\n\n### For Fourslash Tests\n1. **Prefer validation over baselines** - Use `verify.currentLineContentIs()` instead of `verify.baseline*()`\n2. **Use simple, focused examples** - Test one feature at a time\n3. **Name markers clearly** - Use descriptive marker names like `/*completion*/`\n4. **Test the simplest form first** - Start with basic cases before complex scenarios\n\n### For Compiler Tests  \n1. **Use clear file names** - Name tests after the feature being tested\n2. **Add explanatory comments** - Document expected behavior with comments\n3. **Test error cases** - Include both valid and invalid code examples\n4. **Keep tests focused** - One primary feature per test file\n\n### General Guidelines\n1. **Make tests deterministic** - Avoid random or environment-dependent behavior\n2. **Use realistic examples** - Test scenarios developers actually encounter  \n3. **Start simple** - Begin with the most basic case of a feature\n4. **Test edge cases** - Include boundary conditions and error scenarios\n\n## Running Specific Tests\n\n```bash\n# Run a specific fourslash test\nnpx hereby runtests --tests=tests/cases/fourslash/completionForObjectProperty.ts\n\n# Run a specific compiler test  \nnpx hereby runtests --tests=tests/cases/compiler/abstractClassUnionInstantiation.ts\n\n# Run tests matching a pattern\nnpx hereby runtests --tests=tests/cases/fourslash/completion*.ts\n```\n\n## Important Guidelines\n\n### 🚨 CRITICAL: Before Finishing Your Work 🚨\n\n**THESE STEPS ARE MANDATORY BEFORE COMMITTING/PUSHING ANY CHANGES:**\n\n1. **MUST RUN:** `npx hereby runtests-parallel` (even though it takes 10-15 minutes)\n2. **MUST RUN:** `npx hereby lint` and fix ALL lint issues\n3. **MUST RUN:** `npx hereby format` as the final step\n\n**❌ PRs that fail these checks will be rejected without review.**\n\n### Keeping Things Tidy\n\n- You can assume lint, tests, and formatting are clean on a fresh clone\n- Only run these verification steps AFTER making changes to code\n- Run `npx hereby lint` and fix ALL issues after making changes\n- Run `npx hereby format` as your final step after making changes\n\n### Test Locations\n\n- Only add testcases in `tests/cases/compiler` or `tests/cases/fourslash`\n- Filenames in `tests/cases/compiler` must always end with `.ts`, not `.d.ts`\n- Do not write direct unit tests as they are almost never the correct test format for our repo\n\n### Performance Expectations\n\n- Running a set of tests may take up to 4 minutes\n- A full test run may take up to 15 minutes\n\n### Working with Issues\n\n- Maintainer comments in the issue should generally take priority over OP's comments\n- Maintainers might give you hints on where to start. They are not always right, but a good place to start\n\n### Debugging Tips\n\nprintf debugging is going to be very useful as you are figuring things out.\nTo do this, use `console.log`, but you'll need to `ts-ignore` it.\nWrite something like this:\n```ts,diff\nfunction checkSomething(n: Node) {\n    doSomething(n);\n+   // @ts-ignore DEBUG CODE ONLY, REMOVE ME WHEN DONE\n+   console.log(`Got node with pos = ${n.pos}`);\n    doSomethingElse(n);\n}\n```\nWe have a lot of enums so you might want to print back their symbolic name, to do this, index back into the name of the enum\n```ts\n   // @ts-ignore DEBUG CODE ONLY, REMOVE ME WHEN DONE\n   console.log(`Got node with kind = ${SyntaxKind[n.kind]}`);\n```\n\n## Recommended Workflow\n\nWhen fixing bugs or implementing features, follow this workflow:\n\n1. **Make a testcase that demonstrates the behavior**\n   - Run it (by itself) and review the baselines it generates to ensure it demonstrates the bug\n   - Add the test and its baselines in one commit\n\n2. **Fix the bug by changing code as appropriate**\n   - Put this fix in another commit\n\n3. **Run the test you wrote again**\n   - Ensure the baselines change in a way that demonstrates that the bug is fixed\n   - Put this baseline diff in its own commit\n\n4. **Add more testing**\n   - Once you've got the basics figured out, enhance your test to cover edge cases and other variations\n   - Run the test again and commit the baseline diff along with the test edit\n\n5. **🚨 MANDATORY: Run all other tests to ensure you didn't break anything**\n   - **REQUIRED:** Run `npx hereby runtests-parallel` and wait for it to finish (10-15 minutes is normal!)\n   - **THIS STEP CANNOT BE SKIPPED** - patience is essential!\n   - Some collateral baseline changes are normal, but review for correctness\n   - Put these diffs in another commit\n\n6. **🚨 MANDATORY: Lint and format your changes**\n   - **REQUIRED:** Run `npx hereby lint` and fix ALL issues\n   - **REQUIRED:** Run `npx hereby format` before you're done\n   - **YOU CANNOT FINISH WITHOUT THESE STEPS**\n   - Double-check your line endings. Source files in this repo typically use CRLF line endings. Fix all line endings to be consistent before you wrap up\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# 🚨 CRITICAL: This Repository Is in Maintenance Mode 🚨\n\n**You MUST read and follow these instructions before taking any coding action in this repository.**\n\nThis repository (`microsoft/TypeScript`) is the JavaScript-based TypeScript compiler and is **effectively closed for general development**. TypeScript 6.0 is the **last JavaScript-based release**. Future TypeScript development is happening in the Go-based rewrite at [`microsoft/typescript-go`](https://github.com/microsoft/typescript-go).\n\nSee [issue #62963](https://github.com/microsoft/TypeScript/issues/62963) and the [TypeScript 7.0 progress blog post](https://devblogs.microsoft.com/typescript/progress-on-typescript-7-december-2025/) for full details.\n\n## ❌ DO NOT create coding PRs for this repository\n\n**Unless the user explicitly acknowledges the above and confirms their change falls into one of these narrow accepted categories:**\n\n- Crashes introduced in 5.9 or 6.0 that **also repro in 7.0** and have a portable fix without behavioral changes\n- Security issues\n- Language service crashes that substantially impact mainline usage\n- Serious regressions from 5.9 that impact a large proportion of users\n- Non-disruptive `lib.d.ts` changes\n\n## Required behavior for coding agents\n\nIf asked to make code changes or create a PR in this repository, you **MUST**:\n\n1. Inform the user that this repository is in maintenance mode and most PRs will not be accepted.\n2. Ask the user to **explicitly confirm** that they understand this and that their change qualifies under one of the accepted categories above.\n3. **Refuse to proceed** until that acknowledgement is given.\n4. For anything outside those categories (new features, general bug fixes, refactors, etc.), direct the user to [`microsoft/typescript-go`](https://github.com/microsoft/typescript-go) instead.\n\n---\n\nFor detailed build instructions, test writing guides, and workflow recommendations, see [`.github/copilot-instructions.md`](.github/copilot-instructions.md).\n","category":"root","tokens":498},{"name":"CLAUDE.md","path":"CLAUDE.md","title":"CLAUDE.md","content":"Read AGENTS.md before proceeding.","category":"root","tokens":9},{"name":"copilot-instructions.md","path":".github/copilot-instructions.md","title":"copilot-instructions.md","content":"# 🚨 CRITICAL: This Repository Is in Maintenance Mode 🚨\n\n**You MUST read and follow these instructions before taking any coding action in this repository.**\n\nThis repository (`microsoft/TypeScript`) is the JavaScript-based TypeScript compiler and is **effectively closed for general development**. TypeScript 6.0 is the **last JavaScript-based release**. Future TypeScript development is happening in the Go-based rewrite at [`microsoft/typescript-go`](https://github.com/microsoft/typescript-go).\n\nSee [issue #62963](https://github.com/microsoft/TypeScript/issues/62963) and the [TypeScript 7.0 progress blog post](https://devblogs.microsoft.com/typescript/progress-on-typescript-7-december-2025/) for full details.\n\n## ❌ DO NOT create coding PRs for this repository\n\n**Unless the user explicitly acknowledges the above and confirms their change falls into one of these narrow accepted categories:**\n\n- Crashes introduced in 5.9 or 6.0 that **also repro in 7.0** and have a portable fix without behavioral changes\n- Security issues\n- Language service crashes that substantially impact mainline usage\n- Serious regressions from 5.9 that impact a large proportion of users\n- Non-disruptive `lib.d.ts` changes\n\n## Required behavior for coding agents\n\nIf asked to make code changes or create a PR in this repository, you **MUST**:\n\n1. Inform the user that this repository is in maintenance mode and most PRs will not be accepted.\n2. Ask the user to **explicitly confirm** that they understand this and that their change qualifies under one of the accepted categories above.\n3. **Refuse to proceed** until that acknowledgement is given.\n4. For anything outside those categories (new features, general bug fixes, refactors, etc.), direct the user to [`microsoft/typescript-go`](https://github.com/microsoft/typescript-go) instead.\n\n---\n\n# Guide for Copilot\n\nThis document provides a concise guide for writing TypeScript fourslash tests and compiler tests, along with build instructions.\n\n## Build Instructions Summary\n\n### Setup\n1. Install Node.js (current or LTS)\n2. Clone the repository: `git clone --depth=1 https://github.com/microsoft/TypeScript`\n3. Install dependencies: `npm ci`\n\n### Common Build Tasks\n```bash\nnpx hereby local             # Build the compiler into built/local\nnpx hereby clean             # Delete the built compiler  \nnpx hereby tests             # Build the test infrastructure\nnpx hereby runtests          # Run all tests\nnpx hereby runtests-parallel # Run tests in parallel 🚨 MANDATORY BEFORE FINISHING!\nnpx hereby runtests --runner=fourslash # Run only fourslash tests\nnpx hereby runtests --runner=compiler # Run only compiler tests\nnpx hereby runtests --tests=<testPath> # Run specific test\nnpx hereby baseline-accept   # Accept new test baselines\nnpx hereby lint              # Run eslint 🚨 MANDATORY BEFORE FINISHING!\nnpx hereby format            # Run code formatting 🚨 MANDATORY BEFORE FINISHING!\n```\n\n## Fourslash Test Syntax Guide\n\nFourslash tests are interactive TypeScript language service tests. They validate IDE features like completions, quick info, navigation, and refactoring.\n\n### Basic Structure\n```typescript\n/// <reference path='fourslash.ts'/>\n\n////code goes here with /*markers*/\n\n// Test assertions go here\n```\n\n### Key Syntax Elements\n\n#### 1. Source Code Definition\nUse `////` to define source code lines:\n```typescript\n////function foo(x: number) {\n////    return x + 1;\n////}\n////let result = foo(/*marker*/42);\n```\n\n#### 2. Markers for Positioning\nUse `/**/` for anonymous markers or `/*name*/` for named markers:\n```typescript\n////let x = /*1*/someValue;\n////let y = /*cursor*/anotherValue;\n```\n\n#### 3. Multi-file Tests\nUse `// @Filename:` to define multiple files:\n```typescript\n// @Filename: /a.ts\n////export const value = 42;\n\n// @Filename: /b.ts  \n////import { value } from './a';\n////console.log(/*marker*/value);\n```\n\n#### 4. Ranges\nUse `[|text|]` to define text ranges:\n```typescript\n////function test() {\n////    [|return 42;|]\n////}\n```\n\n### Common API Patterns\n\n#### Navigation & Positioning\n```typescript\ngoTo.marker(\"markerName\");         // Navigate to marker\ngoTo.marker();                     // Navigate to anonymous marker /**/\n```\n\n#### Verification (Prefer these over baselines)\n```typescript\nverify.currentLineContentIs(\"expected content\");\nverify.completions({ includes: \"itemName\" });\nverify.completions({ excludes: \"itemName\" });\nverify.quickInfoIs(\"expected info\");\nverify.codeFix({\n    description: \"Fix description\",\n    newFileContent: \"expected content after fix\"\n});\n```\n\n#### Completions Testing\n```typescript\nverify.completions({ \n    marker: \"1\",\n    includes: { name: \"foo\", source: \"/a\", hasAction: true },\n    isNewIdentifierLocation: true,\n    preferences: { includeCompletionsForModuleExports: true }\n});\n```\n\n#### Code Fixes Testing\n```typescript\nverify.codeFix({\n    description: \"Add missing property\",\n    index: 0,\n    newFileContent: `class C {\n    property: string;\n    method() { this.property = \"value\"; }\n}`\n});\n```\n\n#### Formatting\n```typescript\nformat.document();\nverify.currentLineContentIs(\"formatted content\");\n```\n\n### Simple Example\n```typescript\n/// <reference path='fourslash.ts'/>\n\n////interface User {\n////    name: string;\n////}\n////\n////const user: User = {\n////    /*completion*/\n////};\n\nverify.completions({\n    marker: \"completion\",\n    includes: { name: \"name\", sortText: \"0\" }\n});\n```\n\n## Compiler Test Syntax Guide\n\nCompiler tests validate TypeScript compilation behavior, type checking, and error reporting.\n\n### Basic Structure\n- Simple `.ts` files in `tests/cases/compiler/`\n- Use comments to indicate expected behavior\n- No special test harness - just TypeScript code\n\n### Compiler Directives\nUse `// @directive: value` for compiler options:\n```typescript\n// @strict: true\n// @target: ES2015\n// @lib: ES2015,DOM\n\nlet x: string = 42; // Error expected\n```\n\n### Common Directives\n```typescript\n// @strict: true/false\n// @noImplicitAny: true/false  \n// @target: ES5/ES2015/ES2020/ESNext\n// @module: commonjs/amd/es6/esnext\n// @lib: ES5,DOM/ES2015/ES2020\n// @declaration: true/false\n// @skipLibCheck: true/false\n```\n\n### Multi-file Tests\n```typescript\n// @Filename: helper.ts\nexport function helper(x: number): string {\n    return x.toString();\n}\n\n// @Filename: main.ts  \nimport { helper } from \"./helper\";\nconst result = helper(42);\n```\n\n### Error Expectations\nUse comments to document expected behavior:\n```typescript\nabstract class Base {\n    abstract method(): void;\n}\n\nclass Derived extends Base {\n    // Missing implementation - should error\n}\n\nnew Base(); // Should error - cannot instantiate abstract class\n```\n\n### Type Testing Patterns\n```typescript\n// Test type inference\nlet inferred = [1, 2, 3]; // Should infer number[]\n\n// Test type compatibility  \ntype A = { x: number };\ntype B = { x: number; y: string };\nlet a: A = { x: 1 };\nlet b: B = { x: 1, y: \"hello\" };\na = b; // Should work - B is assignable to A\nb = a; // Should error - A missing property y\n```\n\n### Simple Example\n```typescript\n// Test that optional properties work correctly\ninterface Config {\n    required: string;\n    optional?: number;\n}\n\nconst config1: Config = { required: \"test\" }; // Should work\nconst config2: Config = { required: \"test\", optional: 42 }; // Should work  \nconst config3: Config = { optional: 42 }; // Should error - missing required\n```\n\n## Test Writing Best Practices\n\n### For Fourslash Tests\n1. **Prefer validation over baselines** - Use `verify.currentLineContentIs()` instead of `verify.baseline*()`\n2. **Use simple, focused examples** - Test one feature at a time\n3. **Name markers clearly** - Use descriptive marker names like `/*completion*/`\n4. **Test the simplest form first** - Start with basic cases before complex scenarios\n\n### For Compiler Tests  \n1. **Use clear file names** - Name tests after the feature being tested\n2. **Add explanatory comments** - Document expected behavior with comments\n3. **Test error cases** - Include both valid and invalid code examples\n4. **Keep tests focused** - One primary feature per test file\n\n### General Guidelines\n1. **Make tests deterministic** - Avoid random or environment-dependent behavior\n2. **Use realistic examples** - Test scenarios developers actually encounter  \n3. **Start simple** - Begin with the most basic case of a feature\n4. **Test edge cases** - Include boundary conditions and error scenarios\n\n## Running Specific Tests\n\n```bash\n# Run a specific fourslash test\nnpx hereby runtests --tests=tests/cases/fourslash/completionForObjectProperty.ts\n\n# Run a specific compiler test  \nnpx hereby runtests --tests=tests/cases/compiler/abstractClassUnionInstantiation.ts\n\n# Run tests matching a pattern\nnpx hereby runtests --tests=tests/cases/fourslash/completion*.ts\n```\n\n## Important Guidelines\n\n### 🚨 CRITICAL: Before Finishing Your Work 🚨\n\n**THESE STEPS ARE MANDATORY BEFORE COMMITTING/PUSHING ANY CHANGES:**\n\n1. **MUST RUN:** `npx hereby runtests-parallel` (even though it takes 10-15 minutes)\n2. **MUST RUN:** `npx hereby lint` and fix ALL lint issues\n3. **MUST RUN:** `npx hereby format` as the final step\n\n**❌ PRs that fail these checks will be rejected without review.**\n\n### Keeping Things Tidy\n\n- You can assume lint, tests, and formatting are clean on a fresh clone\n- Only run these verification steps AFTER making changes to code\n- Run `npx hereby lint` and fix ALL issues after making changes\n- Run `npx hereby format` as your final step after making changes\n\n### Test Locations\n\n- Only add testcases in `tests/cases/compiler` or `tests/cases/fourslash`\n- Filenames in `tests/cases/compiler` must always end with `.ts`, not `.d.ts`\n- Do not write direct unit tests as they are almost never the correct test format for our repo\n\n### Performance Expectations\n\n- Running a set of tests may take up to 4 minutes\n- A full test run may take up to 15 minutes\n\n### Working with Issues\n\n- Maintainer comments in the issue should generally take priority over OP's comments\n- Maintainers might give you hints on where to start. They are not always right, but a good place to start\n\n### Debugging Tips\n\nprintf debugging is going to be very useful as you are figuring things out.\nTo do this, use `console.log`, but you'll need to `ts-ignore` it.\nWrite something like this:\n```ts,diff\nfunction checkSomething(n: Node) {\n    doSomething(n);\n+   // @ts-ignore DEBUG CODE ONLY, REMOVE ME WHEN DONE\n+   console.log(`Got node with pos = ${n.pos}`);\n    doSomethingElse(n);\n}\n```\nWe have a lot of enums so you might want to print back their symbolic name, to do this, index back into the name of the enum\n```ts\n   // @ts-ignore DEBUG CODE ONLY, REMOVE ME WHEN DONE\n   console.log(`Got node with kind = ${SyntaxKind[n.kind]}`);\n```\n\n## Recommended Workflow\n\nWhen fixing bugs or implementing features, follow this workflow:\n\n1. **Make a testcase that demonstrates the behavior**\n   - Run it (by itself) and review the baselines it generates to ensure it demonstrates the bug\n   - Add the test and its baselines in one commit\n\n2. **Fix the bug by changing code as appropriate**\n   - Put this fix in another commit\n\n3. **Run the test you wrote again**\n   - Ensure the baselines change in a way that demonstrates that the bug is fixed\n   - Put this baseline diff in its own commit\n\n4. **Add more testing**\n   - Once you've got the basics figured out, enhance your test to cover edge cases and other variations\n   - Run the test again and commit the baseline diff along with the test edit\n\n5. **🚨 MANDATORY: Run all other tests to ensure you didn't break anything**\n   - **REQUIRED:** Run `npx hereby runtests-parallel` and wait for it to finish (10-15 minutes is normal!)\n   - **THIS STEP CANNOT BE SKIPPED** - patience is essential!\n   - Some collateral baseline changes are normal, but review for correctness\n   - Put these diffs in another commit\n\n6. **🚨 MANDATORY: Lint and format your changes**\n   - **REQUIRED:** Run `npx hereby lint` and fix ALL issues\n   - **REQUIRED:** Run `npx hereby format` before you're done\n   - **YOU CANNOT FINISH WITHOUT THESE STEPS**\n   - Double-check your line endings. Source files in this repo typically use CRLF line endings. Fix all line endings to be consistent before you wrap up\n","category":".github","tokens":3051}]}