* Allowed non-this, non-super code before super call in derived classes Fixes #8277. It feels wrong to put a new `forEachChild` loop in the checker, though in the vast majority of user files this will be a very quick one. Is there a better way to check for a reference to `super` or `this`? * Used new isNewThisScope utility and dummy prop in baselines * Accounted for parameters and get/set accessor bodies * Accounted for class extensions * (node|statement)RefersToSuperOrThis wasn't checking root level scope boundaries ```ts function () { return this; } ``` It was immediately going to `ts.forEachChild` so the statement itself wasn't being counted as a new `this` scope. * Better 'references' name and comments; accounted for more method edge case * Limited super calls to root-level statements in constructor bodies As per discussion in the issue, it would be ideal to consider any block that always ends up calling to super() the equivalent of a root-level super() statement. This would be valid: ```ts foo = 1; constructor() { condition() ? super(1) : super(0); this.foo; } ``` ...as it would compile to the equivalent of: ```ts function () { condition() ? super(1) : super(0); this.foo = 1; this.foo; } That change would a bit more intense and I'm very timid, so leaving it out of this PR. In the meantime the requirement is that the super() statement must itself be root-level. * Fixed error number following 'master' merge * Added decorator test cases * Again allowed arrow functions * Accepted new baselines * Added allowance for (super()) * Reworked emitter transforms for ES this binding semantics In trying to adjust to rbuckton's PR feedback, this orders derived class constructor bodies into five sections: 1. Pre-`super()` code 2. The `super()` call itself 3. Class properties with initializers 4. Parameter properties 5. The rest of the constructor I've looked through the updated baselines and it looks like they're generally better than before. Within the existing test cases that result in semantic errors for `this` access before `super`, several previously resulted in a global `_this` being created; now, they correctly defer referring to `_this` until it's assigned to `_super.call(this) || this`. * Used skipOuterExpressions when diving for super()s; fix prop ordering * Allow direct var _this = super() when no pre-super() statements; lint fixes * Always with the TSLint * One last touchup: skipOuterExpressions in es2015 transformer * Fixed new lint complaint in utilities.ts * Again added a falls-through; it'd be swell if I could run linting locally * This time I think I got it * Well at least the error is a different one * Undid irrelevant whitespace changes * Mostly addressed private/field issues * Accepted derivedClassSuperProperties baseline * Lint fix, lovely * Remove now-unnecesary comment * First round of feedback * Moved prologue statements to start of statements * Added consideration for super statements in loops and the like * Ordering and a _this_1 test * Missed the one change I needed... * First round of feedback corrections * Feedback round two: statements * Feedback: used more direct statements * Fixed classFields emit to not duplicate temp variables * Refactored es2015 helper to be less overloaded * Accounted for parentheses * Simpler feedback: -1, and emptyArray * Next feedback: superStatementIndex * Feedback: simplified to no longer create slice arrays * Adjusted for default and rest parameters * Added test case for commas * Corrected comment ranges * Handled comments after super, with tests * Fixed Bad/Late super baselines * Remove unused param and unnecessary baseline comments Co-authored-by: Orta Therox <orta.therox@gmail.com> Co-authored-by: Ron Buckton <ron.buckton@microsoft.com>
TypeScript
TypeScript is a language for application-scale JavaScript. TypeScript adds optional types to JavaScript that support tools for large-scale JavaScript applications for any browser, for any host, on any OS. TypeScript compiles to readable, standards-based JavaScript. Try it out at the playground, and stay up to date via our blog and Twitter account.
Find others who are using TypeScript at our community page.
Installing
For the latest stable version:
npm install -g typescript
For our nightly builds:
npm install -g typescript@next
Contribute
There are many ways to contribute to TypeScript.
- Submit bugs and help us verify fixes as they are checked in.
- Review the source code changes.
- Engage with other TypeScript users and developers on StackOverflow.
- Help each other in the TypeScript Community Discord.
- Join the #typescript discussion on Twitter.
- Contribute bug fixes.
- Read the archived language specification (docx, pdf, md).
This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.
Documentation
Building
In order to build the TypeScript compiler, ensure that you have Git and Node.js installed.
Clone a copy of the repo:
git clone https://github.com/microsoft/TypeScript.git
Change to the TypeScript directory:
cd TypeScript
Install Gulp tools and dev dependencies:
npm install -g gulp
npm ci
Use one of the following to build and test:
gulp local # Build the compiler into built/local.
gulp clean # Delete the built compiler.
gulp LKG # Replace the last known good with the built one.
# Bootstrapping step to be executed when the built compiler reaches a stable state.
gulp tests # Build the test infrastructure using the built compiler.
gulp runtests # Run tests using the built compiler and test infrastructure.
# You can override the specific suite runner used or specify a test for this command.
# Use --tests=<testPath> for a specific test and/or --runner=<runnerName> for a specific suite.
# Valid runners include conformance, compiler, fourslash, project, user, and docker
# The user and docker runners are extended test suite runners - the user runner
# works on disk in the tests/cases/user directory, while the docker runner works in containers.
# You'll need to have the docker executable in your system path for the docker runner to work.
gulp runtests-parallel # Like runtests, but split across multiple threads. Uses a number of threads equal to the system
# core count by default. Use --workers=<number> to adjust this.
gulp baseline-accept # This replaces the baseline test results with the results obtained from gulp runtests.
gulp lint # Runs eslint on the TypeScript source.
gulp help # List the above commands.
Usage
node built/local/tsc.js hello.ts
Roadmap
For details on our planned features and future direction please refer to our roadmap.