You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
sed -i -e 's/const version = `${versionMajorMinor}.0-.*`/const version = `${versionMajorMinor}.0-${{ github.event.client_payload.core_tag || 'dev' }}`/g' src/compiler/corePublic.ts
2. A copy of the TypeScript code. See the next steps for instructions.
55
+
3.[Node](https://nodejs.org), which runs JavaScript locally. Current or LTS will both work.
56
+
4. An editor. [VS Code](https://code.visualstudio.com) is the best place to start for TypeScript.
57
+
5. The gulp command line tool, for building and testing changes. See the next steps for how to install it.
58
+
59
+
## Get Started
60
+
61
+
1. Install node using the version you downloaded from [nodejs.org](https://nodejs.org).
62
+
2. Open a terminal.
63
+
3. Make a fork—your own copy—of TypeScript on your GitHub account, then make a clone—a local copy—on your computer. ([Here are some step-by-step instructions](https://github.com/anitab-org/mentorship-android/wiki/Fork%2C-Clone-%26-Remote)). Add `--depth=1` to the end of the `git clone` command to save time.
64
+
4. Install the gulp command line tool: `npm install -g gulp-cli`
65
+
5. Change to the TypeScript folder you made: `cd TypeScript`
66
+
6. Install dependencies: `npm ci`
67
+
7. Make sure everything builds and tests pass: `gulp runtests-parallel`
68
+
8. Open the Typescript folder in your editor.
69
+
9. Follow the directions below to add and debug a test.
70
+
50
71
## Tips
51
72
52
73
### Faster clones
@@ -65,8 +86,6 @@ TypeScript is currently accepting contributions in the form of bug fixes. A bug
65
86
66
87
Features (things that add new or improved functionality to TypeScript) may be accepted, but will need to first be approved (labelled ["help wanted"](https://github.com/Microsoft/TypeScript/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22) or in the "Backlog" milestone) by a TypeScript project maintainer in the suggestion issue. Features with language design impact, or that are adequately satisfied with external tools, will not be accepted.
67
88
68
-
Design changes will not be accepted at this time. If you have a design change proposal, please log a suggestion issue.
69
-
70
89
## Legal
71
90
72
91
You will need to complete a Contributor License Agreement (CLA). Briefly, this agreement testifies that you are granting us permission to use the submitted change according to the terms of the project's license, and that the work being submitted is under appropriate copyright. Upon submitting a pull request, you will automatically be given instructions on how to sign the CLA.
@@ -76,16 +95,11 @@ You will need to complete a Contributor License Agreement (CLA). Briefly, this a
76
95
Your pull request should:
77
96
78
97
* Include a description of what your change intends to do
79
-
* Be a child commit of a reasonably recent commit in the **master** branch
80
-
* Requests need not be a single commit, but should be a linear sequence of commits (i.e. no merge commits in your PR)
81
-
* It is desirable, but not necessary, for the tests to pass at each commit
82
-
* Have clear commit messages
83
-
* e.g. "Minor refactor in goToTypeDefinition", "Fix iterated type in for-await-of", "Add test for preserveWatchOutput on command line"
98
+
* Be based on reasonably recent commit in the **master** branch
84
99
* Include adequate tests
85
100
* At least one test should fail in the absence of your non-test code changes. If your PR does not match this criteria, please specify why
86
101
* Tests should include reasonable permutations of the target fix/change
87
102
* Include baseline changes with your change
88
-
* All changed code must have 100% code coverage
89
103
* Follow the code conventions described in [Coding guidelines](https://github.com/Microsoft/TypeScript/wiki/Coding-guidelines)
90
104
* To avoid line ending issues, set `autocrlf = input` and `whitespace = cr-at-eol` in your git configuration
91
105
@@ -149,37 +163,35 @@ You can also use the [provided VS Code launch configuration](./.vscode/launch.te
149
163
150
164
## Adding a Test
151
165
152
-
To add a new test case, simply place a `.ts` file in `tests\cases\compiler`containing code that exemplifies the bugfix or change you are making.
166
+
To add a new test case, add a `.ts` file in `tests\cases\compiler`with code that shows the your bug is now fixed, or your new feature now works.
153
167
154
168
These files support metadata tags in the format `// @metaDataName: value`.
155
169
The supported names and values are the same as those supported in the compiler itself, with the addition of the `fileName` flag.
156
170
`fileName` tags delimit sections of a file to be used as separate compilation units.
157
-
They are useful for tests relating to modules.
171
+
They are useful for testing modules.
158
172
See below for examples.
159
173
160
-
**Note** that if you have a test corresponding to a specific spec compliance item, you can place it in `tests\cases\conformance` in an appropriately-named subfolder.
161
-
**Note** that filenames here must be distinct from all other compiler testcase names, so you may have to work a bit to find a unique name if it's something common.
174
+
**Note** that if you have a test corresponding to a specific area of spec compliance, you can put it in the appropriate subfolder of `tests\cases\conformance`.
175
+
**Note** that test filenames must be distinct from all other test names, so you may have to work a bit to find a unique name if it's something common.
162
176
163
177
### Tests for multiple files
164
178
165
-
When one needs to test for scenarios which require multiple files, it is useful to use the `fileName` metadata tag as such:
179
+
When you need to multiple files in a single test, use the `filename`tag:
166
180
167
-
```TypeScript
168
-
// @fileName: file1.ts
181
+
```ts
182
+
// @filename: file1.ts
169
183
exportfunction f() {
170
184
}
171
185
172
-
// @fileName: file2.ts
186
+
// @filename: file2.ts
173
187
import { fasg } from"file1";
174
188
175
189
var x =g();
176
190
```
177
191
178
-
One can also write a project test, but it is slightly more involved.
179
-
180
192
## Managing the Baselines
181
193
182
-
Compiler testcases generate baselines that track the emitted `.js`, the errors produced by the compiler, and the type of each expression in the file. Additionally, some testcases opt in to baselining the source map output.
194
+
Compiler tests generate baselines: one file each for the emitted `.js`, the errors produced by the compiler, the type of each expression, and symbol for each identifier. Additionally, some tests generate baselines for the source map output.
183
195
184
196
When a change in the baselines is detected, the test will fail. To inspect changes vs the expected baselines, use
185
197
@@ -193,7 +205,8 @@ After verifying that the changes in the baselines are correct, run
193
205
gulp baseline-accept
194
206
```
195
207
196
-
to establish the new baselines as the desired behavior. This will change the files in `tests\baselines\reference`, which should be included as part of your commit. It's important to carefully validate changes in the baselines.
208
+
This will change the files in `tests\baselines\reference`, which should be included as part of your commit.
209
+
Be sure to validate the changes carefully -- apparently unrelated changes to baselines can be clues about something you didn't think of.
0 commit comments