From acb5b385fdcbca38d83490996a77c44d836ed3a0 Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Wed, 2 Jul 2025 15:16:25 +0000 Subject: [PATCH 1/6] Initial plan From 7d455085b31191e6fe4dc9be0058bbd86bcd02a0 Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Wed, 2 Jul 2025 16:28:00 +0000 Subject: [PATCH 2/6] Update copilot instructions and setup steps with new information Co-authored-by: jakebailey <5341706+jakebailey@users.noreply.github.com> --- .github/copilot-instructions.md | 180 ++++++++++++---------- .github/workflows/copilot-setup-steps.yml | 3 + 2 files changed, 99 insertions(+), 84 deletions(-) diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md index 9be89da690..d8294cc926 100644 --- a/.github/copilot-instructions.md +++ b/.github/copilot-instructions.md @@ -1,85 +1,97 @@ -This is the codebase for a native port of the TypeScript compiler and language server. -The source directories of interest that we have are: - -- `internal` - Contains the compiler and language server code. -- `_extension` - Contains a preview VS Code extension code that integrates with the language server. -- `_submodules/TypeScript` - the stable TypeScript repository, checked out at the appropriate commit. - -Most of our development takes place in the `internal` directory, and most behaviors can be tested via compiler tests. - -Most development on the codebase is in Go. -Standard Go commands and practices apply, but we primarily use a tool called `hereby` to build, run tests, and other tasks. -Feel free to install `hereby` globally (`npm install -g hereby`) if it is easier, and run `hereby --list` to see all available commands. - -```sh -hereby build # Build the project -hereby test # Run tests -hereby format # Format the code -hereby lint # Run linters -``` - -Always make sure code is formatted, linted, and tested before sending a pull request. - -## Compiler Features, Fixes, and Tests - -When fixing a bug or implementing a new feature, at least one minimal test case should always be added in advance to verify the fix. -This project primarily uses snapshot/baseline/golden tests rather than unit tests. -New compiler tests are written in `.ts`/`.tsx` files in the directory `testdata/tests/cases/compiler/`, and are written in the following format: - -```ts -// @target: esnext -// @module: preserve -// @moduleResolution: bundler -// @strict: true -// @checkJs: true - -// @filename: fileA.ts - -export interface Person { - name: string; - age: number; -} - -// @filename: fileB.js - -/** @import { Person } from "./fileA" */ - -/** -* @param {Person} person -*/ -function greet(person) { - console.log(`Hello, ${person.name}!`); -} -``` - -Tests don't always need the above `@option`s specified, but they are common to specify or modify. -Tests can be run with multiple settings for a given option by using a comma-separated list (e.g. `@option: settingA,settingB`). -`@filename` is only required when a test has multiple files, or when writing a test for a single JavaScript file (where `allowJs` or `checkJs` is enabled). -You can see more tests in `_submodules/TypeScript/tests/cases/{compiler,conformance}`. - -When tests are run, they will produce output files in the `testdata/baselines/local` directory. -**Test failures are fine** if they are just differences in output files. -A reduction/removal of `.diff` file baselines is **ideal** because it indicates the port has converged in behavior with the stable TypeScript codebase. -The new outputs can be diffed against `testdata/baselines/reference` to see if the output has changed. - -Running - -```sh -npx hereby baseline-accept -``` - -will update the baselines/snapshots, and `git diff` can be used to see what has changed. - -It is ideal to implement features and fixes in the following order, and commit code after each step: - -1. Write a minimal test case, or test cases, that demonstrate the bug or feature. -1. Run the tests to ensure it fails (for a bug) or passes (for a feature). Then accept generated baselines (not applicable in the case of a crash). -1. Implement the fix or feature. -1. Run the tests again to ensure everything is working correctly. Accept the baselines. - -It is fine to implement more and more of a feature across commits, but be sure to update baselines every time so that reviewers can measure progress. - -# Other Instructions - -- Do not add or change existing dependencies unless asked to. +This is the codebase for a native port of the TypeScript compiler and language server. +The source directories of interest that we have are: + +- `internal` - Contains the compiler and language server code. +- `_extension` - Contains a preview VS Code extension code that integrates with the language server. +- `_submodules/TypeScript` - the stable TypeScript repository, checked out at the appropriate commit. + +Most of our development takes place in the `internal` directory, and most behaviors can be tested via compiler tests. + +Most development on the codebase is in Go. +Standard Go commands and practices apply, but we primarily use a tool called `hereby` to build, run tests, and other tasks. +Feel free to install `hereby` globally (`npm install -g hereby`) if it is easier, and run `hereby --list` to see all available commands. + +```sh +hereby build # Build the project +hereby test # Run tests +hereby format # Format the code +hereby lint # Run linters +``` + +Always make sure code is formatted, linted, and tested before sending a pull request. + +## Running Specific Tests + +To run a specific compiler test: +- For submodule tests in `_submodules/TypeScript`: `go test -run='TestSubmodule/' ./internal/testrunner`. +- For local tests in `testdata/tests/cases`: `go test -run='TestLocal/' ./internal/testrunner`. + +## Compiler Features, Fixes, and Tests + +When fixing a bug or implementing a new feature, at least one minimal test case should always be added in advance to verify the fix. +This project primarily uses snapshot/baseline/golden tests rather than unit tests. +New compiler tests are written in `.ts`/`.tsx` files in the directory `testdata/tests/cases/compiler/`, and are written in the following format: + +**Note:** Issues with editor features cannot be tested with compiler tests in `testdata/tests/cases/`. Editor functionality requires integration testing with the language server. + +```ts +// @target: esnext +// @module: preserve +// @moduleResolution: bundler +// @strict: true +// @checkJs: true + +// @filename: fileA.ts + +export interface Person { + name: string; + age: number; +} + +// @filename: fileB.js + +/** @import { Person } from "./fileA" */ + +/** +* @param {Person} person +*/ +function greet(person) { + console.log(`Hello, ${person.name}!`); +} +``` + +Tests don't always need the above `@option`s specified, but they are common to specify or modify. +Tests can be run with multiple settings for a given option by using a comma-separated list (e.g. `@option: settingA,settingB`). +`@filename` is only required when a test has multiple files, or when writing a test for a single JavaScript file (where `allowJs` or `checkJs` is enabled). +You can see more tests in `_submodules/TypeScript/tests/cases/{compiler,conformance}`. + +When tests are run, they will produce output files in the `testdata/baselines/local` directory. +**Test failures are fine** if they are just differences in output files. +A reduction/removal of `.diff` file baselines is **ideal** because it indicates the port has converged in behavior with the stable TypeScript codebase. +The new outputs can be diffed against `testdata/baselines/reference` to see if the output has changed. + +Running + +```sh +npx hereby baseline-accept +``` + +will update the baselines/snapshots, and `git diff` can be used to see what has changed. + +It is ideal to implement features and fixes in the following order, and commit code after each step: + +1. Write a minimal test case, or test cases, that demonstrate the bug or feature. +1. Run the tests to ensure it fails (for a bug) or passes (for a feature). Then accept generated baselines (not applicable in the case of a crash). +1. Implement the fix or feature. +1. Run the tests again to ensure everything is working correctly. Accept the baselines. + +It is fine to implement more and more of a feature across commits, but be sure to update baselines every time so that reviewers can measure progress. + +## Code Porting Reference + +This code is ported from code present in `_submodules/TypeScript`. When implementing features or fixing bugs, those files should be searched for similar functions when code is either missing or potentially wrong. The TypeScript submodule serves as the reference implementation for behavior and functionality. + +# Other Instructions + +- Do not add or change existing dependencies unless asked to. \ No newline at end of file diff --git a/.github/workflows/copilot-setup-steps.yml b/.github/workflows/copilot-setup-steps.yml index 1aef70e6c2..3469648fb7 100644 --- a/.github/workflows/copilot-setup-steps.yml +++ b/.github/workflows/copilot-setup-steps.yml @@ -28,3 +28,6 @@ jobs: - run: npm ci # pull dprint caches before network access is blocked - run: npx hereby check:format || true + # cache build and lint operations + - run: npx hereby build || true + - run: npx hereby lint || true From 5d8ce8c2aaac37b3cd32d90006a6439533a77690 Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Wed, 2 Jul 2025 16:43:46 +0000 Subject: [PATCH 3/6] Fix line endings and update Go version as requested Co-authored-by: jakebailey <5341706+jakebailey@users.noreply.github.com> --- .github/actions/setup-go/action.yml | 3 +- .github/copilot-instructions.md | 192 ++++++++++++++-------------- 2 files changed, 98 insertions(+), 97 deletions(-) diff --git a/.github/actions/setup-go/action.yml b/.github/actions/setup-go/action.yml index fd35afd493..d90be3e70d 100644 --- a/.github/actions/setup-go/action.yml +++ b/.github/actions/setup-go/action.yml @@ -4,7 +4,8 @@ description: Setup Go inputs: go-version: description: Go version range to set up. - default: '>=1.24.0' + # Updated to 1.25.0-rc.1 to improve compilation time + default: '>=1.25.0-rc.1' cache-name: description: Name of scoped cache for this set up. default: 'cache' diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md index d8294cc926..917dde3083 100644 --- a/.github/copilot-instructions.md +++ b/.github/copilot-instructions.md @@ -1,97 +1,97 @@ -This is the codebase for a native port of the TypeScript compiler and language server. -The source directories of interest that we have are: - -- `internal` - Contains the compiler and language server code. -- `_extension` - Contains a preview VS Code extension code that integrates with the language server. -- `_submodules/TypeScript` - the stable TypeScript repository, checked out at the appropriate commit. - -Most of our development takes place in the `internal` directory, and most behaviors can be tested via compiler tests. - -Most development on the codebase is in Go. -Standard Go commands and practices apply, but we primarily use a tool called `hereby` to build, run tests, and other tasks. -Feel free to install `hereby` globally (`npm install -g hereby`) if it is easier, and run `hereby --list` to see all available commands. - -```sh -hereby build # Build the project -hereby test # Run tests -hereby format # Format the code -hereby lint # Run linters -``` - -Always make sure code is formatted, linted, and tested before sending a pull request. - -## Running Specific Tests - -To run a specific compiler test: -- For submodule tests in `_submodules/TypeScript`: `go test -run='TestSubmodule/' ./internal/testrunner`. -- For local tests in `testdata/tests/cases`: `go test -run='TestLocal/' ./internal/testrunner`. - -## Compiler Features, Fixes, and Tests - -When fixing a bug or implementing a new feature, at least one minimal test case should always be added in advance to verify the fix. -This project primarily uses snapshot/baseline/golden tests rather than unit tests. -New compiler tests are written in `.ts`/`.tsx` files in the directory `testdata/tests/cases/compiler/`, and are written in the following format: - -**Note:** Issues with editor features cannot be tested with compiler tests in `testdata/tests/cases/`. Editor functionality requires integration testing with the language server. - -```ts -// @target: esnext -// @module: preserve -// @moduleResolution: bundler -// @strict: true -// @checkJs: true - -// @filename: fileA.ts - -export interface Person { - name: string; - age: number; -} - -// @filename: fileB.js - -/** @import { Person } from "./fileA" */ - -/** -* @param {Person} person -*/ -function greet(person) { - console.log(`Hello, ${person.name}!`); -} -``` - -Tests don't always need the above `@option`s specified, but they are common to specify or modify. -Tests can be run with multiple settings for a given option by using a comma-separated list (e.g. `@option: settingA,settingB`). -`@filename` is only required when a test has multiple files, or when writing a test for a single JavaScript file (where `allowJs` or `checkJs` is enabled). -You can see more tests in `_submodules/TypeScript/tests/cases/{compiler,conformance}`. - -When tests are run, they will produce output files in the `testdata/baselines/local` directory. -**Test failures are fine** if they are just differences in output files. -A reduction/removal of `.diff` file baselines is **ideal** because it indicates the port has converged in behavior with the stable TypeScript codebase. -The new outputs can be diffed against `testdata/baselines/reference` to see if the output has changed. - -Running - -```sh -npx hereby baseline-accept -``` - -will update the baselines/snapshots, and `git diff` can be used to see what has changed. - -It is ideal to implement features and fixes in the following order, and commit code after each step: - -1. Write a minimal test case, or test cases, that demonstrate the bug or feature. -1. Run the tests to ensure it fails (for a bug) or passes (for a feature). Then accept generated baselines (not applicable in the case of a crash). -1. Implement the fix or feature. -1. Run the tests again to ensure everything is working correctly. Accept the baselines. - -It is fine to implement more and more of a feature across commits, but be sure to update baselines every time so that reviewers can measure progress. - -## Code Porting Reference - -This code is ported from code present in `_submodules/TypeScript`. When implementing features or fixing bugs, those files should be searched for similar functions when code is either missing or potentially wrong. The TypeScript submodule serves as the reference implementation for behavior and functionality. - -# Other Instructions - -- Do not add or change existing dependencies unless asked to. +This is the codebase for a native port of the TypeScript compiler and language server. +The source directories of interest that we have are: + +- `internal` - Contains the compiler and language server code. +- `_extension` - Contains a preview VS Code extension code that integrates with the language server. +- `_submodules/TypeScript` - the stable TypeScript repository, checked out at the appropriate commit. + +Most of our development takes place in the `internal` directory, and most behaviors can be tested via compiler tests. + +Most development on the codebase is in Go. +Standard Go commands and practices apply, but we primarily use a tool called `hereby` to build, run tests, and other tasks. +Feel free to install `hereby` globally (`npm install -g hereby`) if it is easier, and run `hereby --list` to see all available commands. + +```sh +hereby build # Build the project +hereby test # Run tests +hereby format # Format the code +hereby lint # Run linters +``` + +Always make sure code is formatted, linted, and tested before sending a pull request. + +## Running Specific Tests + +To run a specific compiler test: +- For submodule tests in `_submodules/TypeScript`: `go test -run='TestSubmodule/' ./internal/testrunner`. +- For local tests in `testdata/tests/cases`: `go test -run='TestLocal/' ./internal/testrunner`. + +## Compiler Features, Fixes, and Tests + +When fixing a bug or implementing a new feature, at least one minimal test case should always be added in advance to verify the fix. +This project primarily uses snapshot/baseline/golden tests rather than unit tests. +New compiler tests are written in `.ts`/`.tsx` files in the directory `testdata/tests/cases/compiler/`, and are written in the following format: + +**Note:** Issues with editor features cannot be tested with compiler tests in `testdata/tests/cases/`. Editor functionality requires integration testing with the language server. + +```ts +// @target: esnext +// @module: preserve +// @moduleResolution: bundler +// @strict: true +// @checkJs: true + +// @filename: fileA.ts + +export interface Person { + name: string; + age: number; +} + +// @filename: fileB.js + +/** @import { Person } from "./fileA" */ + +/** +* @param {Person} person +*/ +function greet(person) { + console.log(`Hello, ${person.name}!`); +} +``` + +Tests don't always need the above `@option`s specified, but they are common to specify or modify. +Tests can be run with multiple settings for a given option by using a comma-separated list (e.g. `@option: settingA,settingB`). +`@filename` is only required when a test has multiple files, or when writing a test for a single JavaScript file (where `allowJs` or `checkJs` is enabled). +You can see more tests in `_submodules/TypeScript/tests/cases/{compiler,conformance}`. + +When tests are run, they will produce output files in the `testdata/baselines/local` directory. +**Test failures are fine** if they are just differences in output files. +A reduction/removal of `.diff` file baselines is **ideal** because it indicates the port has converged in behavior with the stable TypeScript codebase. +The new outputs can be diffed against `testdata/baselines/reference` to see if the output has changed. + +Running + +```sh +npx hereby baseline-accept +``` + +will update the baselines/snapshots, and `git diff` can be used to see what has changed. + +It is ideal to implement features and fixes in the following order, and commit code after each step: + +1. Write a minimal test case, or test cases, that demonstrate the bug or feature. +1. Run the tests to ensure it fails (for a bug) or passes (for a feature). Then accept generated baselines (not applicable in the case of a crash). +1. Implement the fix or feature. +1. Run the tests again to ensure everything is working correctly. Accept the baselines. + +It is fine to implement more and more of a feature across commits, but be sure to update baselines every time so that reviewers can measure progress. + +## Code Porting Reference + +This code is ported from code present in `_submodules/TypeScript`. When implementing features or fixing bugs, those files should be searched for similar functions when code is either missing or potentially wrong. The TypeScript submodule serves as the reference implementation for behavior and functionality. + +# Other Instructions + +- Do not add or change existing dependencies unless asked to. \ No newline at end of file From d12947eb5b06c28976d548c0afdab7ef998c1ebf Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Wed, 2 Jul 2025 16:53:30 +0000 Subject: [PATCH 4/6] Move Go version override to copilot-setup-steps instead of setup-go action Co-authored-by: jakebailey <5341706+jakebailey@users.noreply.github.com> --- .github/actions/setup-go/action.yml | 3 +-- .github/workflows/copilot-setup-steps.yml | 2 ++ 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/.github/actions/setup-go/action.yml b/.github/actions/setup-go/action.yml index d90be3e70d..fd35afd493 100644 --- a/.github/actions/setup-go/action.yml +++ b/.github/actions/setup-go/action.yml @@ -4,8 +4,7 @@ description: Setup Go inputs: go-version: description: Go version range to set up. - # Updated to 1.25.0-rc.1 to improve compilation time - default: '>=1.25.0-rc.1' + default: '>=1.24.0' cache-name: description: Name of scoped cache for this set up. default: 'cache' diff --git a/.github/workflows/copilot-setup-steps.yml b/.github/workflows/copilot-setup-steps.yml index 3469648fb7..222d1f5108 100644 --- a/.github/workflows/copilot-setup-steps.yml +++ b/.github/workflows/copilot-setup-steps.yml @@ -23,6 +23,8 @@ jobs: - uses: dtolnay/rust-toolchain@fcf085fcb4b4b8f63f96906cd713eb52181b5ea4 # stable - uses: ./.github/actions/setup-go with: + # Updated to 1.25.0-rc.1 to improve compilation time + go-version: '>=1.25.0-rc.1' cache-name: copilot-setup-steps - run: npm i -g @playwright/mcp@0.0.28 - run: npm ci From c9b862d96c297c97b98c8fecc7808c847a412f92 Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Wed, 2 Jul 2025 17:20:31 +0000 Subject: [PATCH 5/6] Address PR feedback: move test commands to examples, update code porting section, use npx hereby Co-authored-by: jakebailey <5341706+jakebailey@users.noreply.github.com> --- .github/copilot-instructions.md | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md index 917dde3083..989f389f53 100644 --- a/.github/copilot-instructions.md +++ b/.github/copilot-instructions.md @@ -9,22 +9,21 @@ Most of our development takes place in the `internal` directory, and most behavi Most development on the codebase is in Go. Standard Go commands and practices apply, but we primarily use a tool called `hereby` to build, run tests, and other tasks. -Feel free to install `hereby` globally (`npm install -g hereby`) if it is easier, and run `hereby --list` to see all available commands. +Run `hereby --list` to see all available commands. ```sh -hereby build # Build the project -hereby test # Run tests -hereby format # Format the code -hereby lint # Run linters +npx hereby build # Build the project +npx hereby test # Run tests +npx hereby format # Format the code +npx hereby lint # Run linters + +# To run a specific compiler test: +go test -run='TestSubmodule/' ./internal/testrunner # For submodule tests in _submodules/TypeScript +go test -run='TestLocal/' ./internal/testrunner # For local tests in testdata/tests/cases ``` Always make sure code is formatted, linted, and tested before sending a pull request. -## Running Specific Tests - -To run a specific compiler test: -- For submodule tests in `_submodules/TypeScript`: `go test -run='TestSubmodule/' ./internal/testrunner`. -- For local tests in `testdata/tests/cases`: `go test -run='TestLocal/' ./internal/testrunner`. ## Compiler Features, Fixes, and Tests @@ -89,7 +88,9 @@ It is fine to implement more and more of a feature across commits, but be sure t ## Code Porting Reference -This code is ported from code present in `_submodules/TypeScript`. When implementing features or fixing bugs, those files should be searched for similar functions when code is either missing or potentially wrong. The TypeScript submodule serves as the reference implementation for behavior and functionality. +The code in `internal` is ported from the code in `_submodules/TypeScript`. +When implementing features or fixing bugs, those files should be searched for similar functions when code is either missing or potentially wrong. +The TypeScript submodule serves as the reference implementation for behavior and functionality. # Other Instructions From 04f83ba1f7b56ed4fce24d0de68ce649875e71c4 Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Wed, 2 Jul 2025 17:33:01 +0000 Subject: [PATCH 6/6] Fix copilot instructions formatting and npx hereby command Co-authored-by: jakebailey <5341706+jakebailey@users.noreply.github.com> --- .github/copilot-instructions.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md index 989f389f53..0e084ab482 100644 --- a/.github/copilot-instructions.md +++ b/.github/copilot-instructions.md @@ -9,7 +9,7 @@ Most of our development takes place in the `internal` directory, and most behavi Most development on the codebase is in Go. Standard Go commands and practices apply, but we primarily use a tool called `hereby` to build, run tests, and other tasks. -Run `hereby --list` to see all available commands. +Run `npx hereby --list` to see all available commands. ```sh npx hereby build # Build the project @@ -22,9 +22,8 @@ go test -run='TestSubmodule/' ./internal/testrunner # For submodule go test -run='TestLocal/' ./internal/testrunner # For local tests in testdata/tests/cases ``` -Always make sure code is formatted, linted, and tested before sending a pull request. - - +Always make sure code is formatted, linted, and tested before sending a pull request. + ## Compiler Features, Fixes, and Tests When fixing a bug or implementing a new feature, at least one minimal test case should always be added in advance to verify the fix.