• Thetsserverlibrary.js entrypoint is now a thin wrapper around the normaltypescript.js entrypoint. It's recommended to switch to the latter where possible. If you were relying on being able to loadtsserverlibrary.js in a non-CJS context (e.g., as a browser global),tsserverlibrary.js will throw, as it's unable to generically load another script into the page; you should switch to usingtypescript.js.

• The TypeScript package now targets ES2020 and requires Node 14.17 or newer. Note that Node 14 is EOL at the end of April 2023.
• Occurrences is request handling ontsserver andLanguageService .getOccurrencesAtPosition are removed now that they have been deprecated for a long time. UsedocumentHighlights request ontsserver andLanguageService.getDocumentHighlights instead.

• TypeScript is now itself implemented using modules (though, the package still contains bundled outputs).
  • The exported API is no longer defined as a "configurable" object, so operations which attempt to modify the package at runtime such asconst ts = require("ts"); ts.readJson = ... will throw.
  • The output files have changed significantly; if you are patching TypeScript, you will definitely need to change your patches.
• typescriptServices.js has been removed; this file was identical totypescript.js, the entrypoint for our npm package.
• protocol.d.ts is no longer included in the package; usetsserverlibrary.d.ts'sts.server.protocol namespace instead.
  • Some elements of the protocol are not actually exported by thets.server.protocol namespace, but were emitted in the oldprotocol.d.ts file, and may need to be accessed off of thets namespace instead. Seehttps://github.com/microsoft/vscode/pull/163365 for an potential way to minimize changes to protocol-using codebases.
• The TypeScript package now targets ES2018 and requires Node 12.20 or newer. Prior to 5.0, our package targeted ES5 syntax and the ES2015 library.
• ts.Map,ts.Set,ts.ESMap,ts.Iterator, and associated types have been removed. The nativeMap,Set,Iterator and associated types should be used instead.
• Thets.Collection andts.ReadonlyCollection types have been removed. These types were unused in our public API, and were declared with the oldMap/Set types (also removed in 5.0).
• Thets.Push type has been removed. This type was only used twice in our API, and its uses have been replaced with arrays for consistency with other parts of our API.
• BuilderProgramHost no longer requires methoduseCaseSensitiveFileNames since its used fromprogram.
• The TypeScript compiler is now compiled withstrictFunctionTypes; to allow this, certain public AST visitor APIs have been modified to better reflect their underlying guarantees, as well as various corrections. The resulting API should be one that is more compatible with projects which also enablestrictFunctionTypes (a recommended option enabled bystrict).
  • TheVisitResult type is no longerundefined by default; if you have writtenVisitResult<Node>, you may need to rewrite it asVisitResult<Node | undefined> to reflect that your visitor may return undefined.
  • Visitor-using APIs now correctly reflect the type of the output, including whether it passed a given type guard test, and whether or not it may be undefined. In order to get the type you expect, you may need to pass atest parameter to verify your expectations and then check the result forundefined (or, modify your visitor to return a more specific type).
• typingOptions along with its propertyenableAutoDiscovery which was deprecated for a long time is not supported any more intsconfig.json andjsconfig.json. UsetypeAcquisition in the config instead.
• This release removes many long-deprecated parts of our public API, including (but not limited to):
  • The top-level Node factory functions (deprecated since TS 4.0) such asts.createIdentifier; use the factory provided in yourTransformationContext orts.factory instead.
  • TheisTypeAssertion function (deprecated since TS 4.0); useisTypeAssertionExpression.
  • The overloads ofcreateConstructorTypeNode andupdateConstructorTypeNode which do not accept modifiers (deprecated since TS 4.2).
  • The overloads ofcreateImportTypeNode andupdateImportTypeNode which do not accept assertions (deprecated since TS 4.6).
  • The overloads ofcreateTypeParameterDeclaration andupdateTypeParameterDeclaration which do not accept modifiers (deprecated since TS 4.6).
  • Node properties and factory function overloads which predate the merger of decorators and modifiers (deprecated since TS 4.8).

As part of an optimization on substitution types,SubstitutionType objects no longer contain thesubstitute property representing the effective substitution (usually an intersection of the base type and the implicit constraint) - instead, they just contain theconstraint property.

For more details,read more on the original pull request.

The current direction of decorators in TC39 means that TypeScript will have to handle a break in terms of placement of decorators.Previously, TypeScript assumed decorators would always be placed prior to all keywords/modifiers.For example

@decoratorexportclassFoo{// ...}

Decorators as currently proposed do not support this syntax.Instead, theexport keyword must precede the decorator.

export @decoratorclassFoo{// ...}

Unfortunately, TypeScript's trees areconcrete rather thanabstract, and our architecture expects syntax tree node fields to be entirely ordered before or after each other.To support both legacy decorators and decorators as proposed, TypeScript will have to gracefully parse, and intersperse, modifiers and decorators.

To do this, it exposes a new type alias calledModifierLike which is aModifier or aDecorator.

exporttypeModifierLike=Modifier|Decorator;

Decorators are now placed in the same field asmodifiers which is now aNodeArray<ModifierLike> when set, and the entire field is deprecated.

- readonly modifiers?: NodeArray<Modifier> | undefined;+ /**+  * @deprecated ...+  * Use `ts.canHaveModifiers()` to test whether a `Node` can have modifiers.+  * Use `ts.getModifiers()` to get the modifiers of a `Node`.+  * ...+  */+ readonly modifiers?: NodeArray<ModifierLike> | undefined;

All existingdecorators properties have been marked as deprecated and will always beundefined if read.The type has also been changed toundefined so that existing tools know to handle them correctly.

- readonly decorators?: NodeArray<Decorator> | undefined;+ /**+  * @deprecated ...+  * Use `ts.canHaveDecorators()` to test whether a `Node` can have decorators.+  * Use `ts.getDecorators()` to get the decorators of a `Node`.+  * ...+  */+ readonly decorators?: undefined;

To avoid all deprecation warnings and other issues, TypeScript now exposes four new functions.There are individual predicates for testing whether a node has support modifiers and decorators, along with respective accessor functions for grabbing them.

functioncanHaveModifiers(node:Node):node isHasModifiers;functiongetModifiers(node:HasModifiers):readonlyModifier[]|undefined;functioncanHaveDecorators(node:Node):node isHasDecorators;functiongetDecorators(node:HasDecorators):readonlyDecorator[]|undefined;

As an example of how to access modifiers off of a node, you can write

constmodifiers=canHaveModifiers(myNode) ?getModifiers(myNode) :undefined;

With the note that each call togetModifiers andgetDecorators may allocate a new array.

For more information, see changes around

• the restructuring of our tree nodes
• the deprecations
• exposing the predicate functions

• resolveTypeReferenceDirectives (both the services and global ts version) now accept an array ofFileReferences as a first argument. If you reimplementresolveTypeReferenceDirectives, you need to handle both thestring[] andFileReference[] cases now.

• factory.createImportSpecifier andfactory.updateImportSpecifier now take anisTypeOnly parameter:

  - createImportSpecifier(propertyName: Identifier | undefined, name: Identifier): ImportSpecifier;+ createImportSpecifier(isTypeOnly: boolean, propertyName: Identifier | undefined, name: Identifier): ImportSpecifier;- updateImportSpecifier(node: ImportSpecifier, propertyName: Identifier | undefined, name: Identifier): ImportSpecifier;+ updateImportSpecifier(node: ImportSpecifier, isTypeOnly: boolean, propertyName: Identifier | undefined, name: Identifier): ImportSpecifier;

  You can read more about this change at theimplementing PR.

• visitNode'slift Takes areadonly Node[] Instead of aNodeArray<Node>

  Thelift function in thevisitNode API now takes areadonly Node[].You cansee details of the change here.

• Type Arguments in JavaScript Are Not Parsed as Type Arguments

  Type arguments were already not allowed in JavaScript, but in TypeScript 4.1, the parser will parse them in a more spec-compliant way.So when writing the following code in a JavaScript file:

  f<T>(100)

  TypeScript will parse it as the following #"(f < T) > (100)">

  (f<T)>(100)

TypeScript 4.0

TypeScript 3.8

TypeScript 3.7

TypeScript 3.1

TypeScript 3.0

TypeScript 2.8

TypeScript 2.6

TypeScript 2.5

TypeScript 2.4

TypeScript 2.2

TypeScript 2.1

TypeScript 1.9

TypeScript 1.7

TypeScript 1.6

CompilerHost interface change (comparing to TypeScript 1.6 beta)

TypeScript 1.5

Program interface changes

All usages of 'filename' and 'Filename' changed to 'fileName' and 'FileName'

ThesyntacticClassifierAbsent parameter for the Classifier.getClassificationsForLine is now required

Changes to TextChange

SourceFile.getLineAndCharacterFromPosition

APIs made internal as they are not intended for use outside of the compiler

typescript_internal.d.ts andtypescriptServices_internal.d.ts have been removed