* Adds experimental support for running TS Server in a web worker This change makes it possible to run a syntax old TS server in a webworker. This is will let serverless versions of VS Code web run the TypeScript extension with minimal changes. As the diff on `server.ts` is difficult to parse, here's an overview of the changes: - Introduce the concept of a `Runtime`. Valid values are `Node` and `Web`. - Move calls to `require` into the functions that use these modules - Wrap existing server logic into `startNodeServer` - Introduce web server with `startWebServer`. This uses a `WorkerSession` - Add a custom version of `ts.sys` for web - Have the worker server start when it is passed an array of arguments in a message In order to make the server logic more clear, this change also tries to reduce the reliance on closures and better group function declarations vs the server spawning logic. **Next Steps** I'd like someone from the TS team to help get these changes into a shippable state. This will involve: - Adddress todo comments - Code cleanup - Make sure these changes do not regress node servers - Determine if we should add a new `tsserver.web.js` file instead of having the web worker logic all live in `tsserver.js` * Shim out directoryExists * Add some regions * Remove some inlined note types Use import types instead * Use switch case for runtime * Review and updates * Enable loading std library d.ts files This implements enough of `ServerHost` that we can load the standard d.ts files using synchronous XMLHttpRequests. I also had to patch some code in `editorServices`. I don't know if these changes are correct and need someone on the TS team to review * Update src/tsserver/webServer.ts * Update src/tsserver/webServer.ts Co-authored-by: Sheetal Nandi <shkamat@microsoft.com> * Addressing feedback * Allow passing in explicit executingFilePath This is required for cases where `self.location` does not point to the directory where all the typings are stored * Adding logging support * Do not create auto import provider in partial semantic mode * Handle lib files by doing path mapping instead * TODO * Add log message This replaces the console based logger with a logger that post log messages back to the host. VS Code will write these messages to its output window * Move code around so that exported functions are set on namespace * Log response * Map the paths back to https: // TODO: is this really needed or can vscode take care of this How do we handle when opening lib.d.ts as response to goto def in open files * If files are not open dont schedule open file project ensure * Should also check if there are no external projects before skipping scheduling Fixes failing tests * Revert "Map the paths back to https:" This reverts commit 0edf650622da11e89e42238523d57f3ea780cdcf. * Revert "TODO" This reverts commit 04a4fe75563ea9fe4747d42a4448d5dd421fbba5. * Revert "Should also check if there are no external projects before skipping scheduling" This reverts commit 7e4939014a414c7651f1fa01516c81a37a10e9be. * Refactoring so we can test the changes out * Feedback Co-authored-by: Sheetal Nandi <shkamat@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.