From d7cb209806c16c45c7fcd8db242c478304bda682 Mon Sep 17 00:00:00 2001 From: Mohamed Hegazy Date: Tue, 15 Jul 2014 17:13:54 -0700 Subject: [PATCH 1/5] add contribution guidlines --- CONTRIBUTING.md | 66 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 66 insertions(+) create mode 100644 CONTRIBUTING.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000000000..be9b121cd9df8 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,66 @@ +## Contributing bug fixes +TypeScript is currently accepting contributions in the form of bug fixes. A bug must have an issue tracking it in the issue tracker that has been approved ("Milestone == Community") by the TypeScript team. Your pull request should include a link to the bug that you are fixing. If you�ve submitted a PR for a bug, please post a comment in the bug to avoid duplication of effort. + +## Contributing features +Features (things that add new or improved functionality to TypeScript) may be accepted, but will need to first be approved (marked as �Milestone == Community� by a TypeScript coordinator with the message "Approved�) in the suggestion issue. Please include [feature] in the title of your forum post. Features with language design impact, or that are adequately satisfied with external tools, will not be accepted. + +Design changes will not be accepted at this time. If you have a design change proposal, please post it to the Language Specification forum. + +## Legal +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. + +Please submit a Contributor License Agreement (CLA) before submitting a pull request. Download the agreement ([Microsoft Contribution License Agreement.docx](https://www.codeplex.com/Download?ProjectName=typescript&DownloadId=822190)), sign, scan, and email it back to . Be sure to include your github user name along with the agreement. Once we have received the signed CLA, we�ll review the request. Please note that we�re currently only accepting pull requests of bug fixes rather than new features. + +## Housekeeping +Your pull request should: + +* Include a description of what your change intends to do +* Be a child commit of a reasonably recent commit in the **master** branch + * Requests need not be a single commit, but should be a linear sequence of commits (i.e. no merge commits in your PR) +* It is desirable, but not necessary, for the tests to pass at each commit +* Have clear commit messages + * e.g. �Refactor feature�, �Fix issue�, �Add tests for issue� +* Include adequate tests + * 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. + * See Creating a TypeScript Compiler Test and Writing TypeScript Language Service Tests for documentation on creating tests + * Tests should include reasonable permutations of the target fix/change + * Include baseline changes with your change + * All changed code must have 100% code coverage +* Follow the existing code conventions in the file + +## Running the Tests +To run all tests, invoke the runtests target using jake: +`jake runtests` + +This will all tests; to run only a specific subset of tests, use: +`jake runtests tests=` +e.g. to run all compiler baseline tests: +`jake runtests tests=compiler` +or to run specifc test:tests\cases\compiler\2dArrays.ts +`jake runtests tests=2dArrays` + +## Adding a Test +To add a new testcase, simply place a .ts file in tests\cases\compiler containing code that exemplifies the bugfix or change you are making. + +These files support metadata tags in the format // @name: value . The supported names and values are: + +* comments, sourcemap, noimplicitany, declaration: true or false (corresponds to the compiler command-line options of the same name) +* target: ES3 or ES5 (same as compiler) +* out, outDir: path (same as compiler) +* module: local, commonjs, or amd (local corresponds to not passing any compiler --module flag) + +**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. +**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. + +## Managing the Baselines +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. + +When a change in the baselines is detected, the test will fail. To inspect changes vs the expected baselines, use +`jake diff` + +After verifying that the changes in the baselines are correct, run +`jake baseline-accept` + +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. + +**Note** that baseline-accept should only be run after a full test run! Accepting baselines after running a subset of tests will delete baseline files for the tests that didn't run. \ No newline at end of file From e59c4d755461ec4845ee9ea2af6314bb2978d773 Mon Sep 17 00:00:00 2001 From: Mohamed Hegazy Date: Tue, 15 Jul 2014 17:13:54 -0700 Subject: [PATCH 2/5] add contribution guidlines --- CONTRIBUTING.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index be9b121cd9df8..c06755cd79fe3 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -2,7 +2,7 @@ TypeScript is currently accepting contributions in the form of bug fixes. A bug must have an issue tracking it in the issue tracker that has been approved ("Milestone == Community") by the TypeScript team. Your pull request should include a link to the bug that you are fixing. If you�ve submitted a PR for a bug, please post a comment in the bug to avoid duplication of effort. ## Contributing features -Features (things that add new or improved functionality to TypeScript) may be accepted, but will need to first be approved (marked as �Milestone == Community� by a TypeScript coordinator with the message "Approved�) in the suggestion issue. Please include [feature] in the title of your forum post. Features with language design impact, or that are adequately satisfied with external tools, will not be accepted. +Features (things that add new or improved functionality to TypeScript) may be accepted, but will need to first be approved (marked as "Milestone == Community" by a TypeScript coordinator with the message "Approved") in the suggestion issue. Please include [feature] in the title of your forum post. Features with language design impact, or that are adequately satisfied with external tools, will not be accepted. Design changes will not be accepted at this time. If you have a design change proposal, please post it to the Language Specification forum. @@ -19,7 +19,7 @@ Your pull request should: * Requests need not be a single commit, but should be a linear sequence of commits (i.e. no merge commits in your PR) * It is desirable, but not necessary, for the tests to pass at each commit * Have clear commit messages - * e.g. �Refactor feature�, �Fix issue�, �Add tests for issue� + * e.g. "Refactor feature", "Fix issue", "Add tests for issue" * Include adequate tests * 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. * See Creating a TypeScript Compiler Test and Writing TypeScript Language Service Tests for documentation on creating tests From 61eea7705604d43591fdf119db3be6ac6121bc2f Mon Sep 17 00:00:00 2001 From: Mohamed Hegazy Date: Tue, 15 Jul 2014 17:38:38 -0700 Subject: [PATCH 3/5] remove some more smart quotes --- CONTRIBUTING.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index c06755cd79fe3..ef16878c7f87b 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,5 +1,5 @@ ## Contributing bug fixes -TypeScript is currently accepting contributions in the form of bug fixes. A bug must have an issue tracking it in the issue tracker that has been approved ("Milestone == Community") by the TypeScript team. Your pull request should include a link to the bug that you are fixing. If you�ve submitted a PR for a bug, please post a comment in the bug to avoid duplication of effort. +TypeScript is currently accepting contributions in the form of bug fixes. A bug must have an issue tracking it in the issue tracker that has been approved ("Milestone == Community") by the TypeScript team. Your pull request should include a link to the bug that you are fixing. If you've submitted a PR for a bug, please post a comment in the bug to avoid duplication of effort. ## Contributing features Features (things that add new or improved functionality to TypeScript) may be accepted, but will need to first be approved (marked as "Milestone == Community" by a TypeScript coordinator with the message "Approved") in the suggestion issue. Please include [feature] in the title of your forum post. Features with language design impact, or that are adequately satisfied with external tools, will not be accepted. @@ -7,9 +7,9 @@ Features (things that add new or improved functionality to TypeScript) may be ac Design changes will not be accepted at this time. If you have a design change proposal, please post it to the Language Specification forum. ## Legal -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. +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. -Please submit a Contributor License Agreement (CLA) before submitting a pull request. Download the agreement ([Microsoft Contribution License Agreement.docx](https://www.codeplex.com/Download?ProjectName=typescript&DownloadId=822190)), sign, scan, and email it back to . Be sure to include your github user name along with the agreement. Once we have received the signed CLA, we�ll review the request. Please note that we�re currently only accepting pull requests of bug fixes rather than new features. +Please submit a Contributor License Agreement (CLA) before submitting a pull request. Download the agreement ([Microsoft Contribution License Agreement.docx](https://www.codeplex.com/Download?ProjectName=typescript&DownloadId=822190)), sign, scan, and email it back to . Be sure to include your github user name along with the agreement. Once we have received the signed CLA, we'll review the request. Please note that we're currently only accepting pull requests of bug fixes rather than new features. ## Housekeeping Your pull request should: @@ -50,7 +50,7 @@ These files support metadata tags in the format // @name: value . The supported * module: local, commonjs, or amd (local corresponds to not passing any compiler --module flag) **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. -**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. +**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. ## Managing the Baselines 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. From 14d4881b2bc47d62480ebf4f4b2371ddfac668e1 Mon Sep 17 00:00:00 2001 From: Mohamed Hegazy Date: Tue, 15 Jul 2014 17:40:28 -0700 Subject: [PATCH 4/5] add new lines --- CONTRIBUTING.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index ef16878c7f87b..daef136f801b6 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -30,13 +30,19 @@ Your pull request should: ## Running the Tests To run all tests, invoke the runtests target using jake: + `jake runtests` This will all tests; to run only a specific subset of tests, use: + `jake runtests tests=` + e.g. to run all compiler baseline tests: + `jake runtests tests=compiler` + or to run specifc test:tests\cases\compiler\2dArrays.ts + `jake runtests tests=2dArrays` ## Adding a Test @@ -56,9 +62,11 @@ These files support metadata tags in the format // @name: value . The supported 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. When a change in the baselines is detected, the test will fail. To inspect changes vs the expected baselines, use + `jake diff` After verifying that the changes in the baselines are correct, run + `jake baseline-accept` 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. From 9f85b15ca1b76212972bc0b5c5db17f95f715a12 Mon Sep 17 00:00:00 2001 From: Mohamed Hegazy Date: Wed, 16 Jul 2014 12:01:36 -0700 Subject: [PATCH 5/5] add code review comments --- CONTRIBUTING.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index daef136f801b6..3198bd03275ee 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -2,9 +2,9 @@ TypeScript is currently accepting contributions in the form of bug fixes. A bug must have an issue tracking it in the issue tracker that has been approved ("Milestone == Community") by the TypeScript team. Your pull request should include a link to the bug that you are fixing. If you've submitted a PR for a bug, please post a comment in the bug to avoid duplication of effort. ## Contributing features -Features (things that add new or improved functionality to TypeScript) may be accepted, but will need to first be approved (marked as "Milestone == Community" by a TypeScript coordinator with the message "Approved") in the suggestion issue. Please include [feature] in the title of your forum post. Features with language design impact, or that are adequately satisfied with external tools, will not be accepted. +Features (things that add new or improved functionality to TypeScript) may be accepted, but will need to first be approved (marked as "Milestone == Community" by a TypeScript coordinator with the message "Approved") in the suggestion issue. Features with language design impact, or that are adequately satisfied with external tools, will not be accepted. -Design changes will not be accepted at this time. If you have a design change proposal, please post it to the Language Specification forum. +Design changes will not be accepted at this time. If you have a design change proposal, please log a suggesion issue. ## Legal 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. @@ -21,8 +21,7 @@ Your pull request should: * Have clear commit messages * e.g. "Refactor feature", "Fix issue", "Add tests for issue" * Include adequate tests - * 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. - * See Creating a TypeScript Compiler Test and Writing TypeScript Language Service Tests for documentation on creating tests + * 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 * Tests should include reasonable permutations of the target fix/change * Include baseline changes with your change * All changed code must have 100% code coverage