A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://github.com/microsoft/TypeScript/wiki/API-Breaking-Changes below:

API Breaking Changes · microsoft/TypeScript Wiki · GitHub

substitute Replaced With constraint on SubstitutionTypes

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

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

Decorators are placed on modifiers on TypeScript's Syntax Trees

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

@decorator
export class Foo {
  // ...
}

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

export @decorator class Foo {
  // ...
}

Unfortunately, TypeScript's trees are concrete rather than abstract, 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 called ModifierLike which is a Modifier or a Decorator.

export type ModifierLike = Modifier | Decorator;

Decorators are now placed in the same field as modifiers which is now a NodeArray<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 existing decorators properties have been marked as deprecated and will always be undefined if read. The type has also been changed to undefined 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.

function canHaveModifiers(node: Node): node is HasModifiers;
function getModifiers(node: HasModifiers): readonly Modifier[] | undefined;

function canHaveDecorators(node: Node): node is HasDecorators;
function getDecorators(node: HasDecorators): readonly Decorator[] | undefined;

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

const modifiers = canHaveModifiers(myNode) ? getModifiers(myNode) : undefined;

With the note that each call to getModifiers and getDecorators may allocate a new array.

For more information, see changes around

CompilerHost interface change (comparing to TypeScript 1.6 beta) Program interface changes

Tip: use ts.getPreEmitDiagnostics(program) to get syntactic, semantic, and global diagnostics for all files

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

Here are the details:

The full list of APIs can be found in this commit

The syntacticClassifierAbsent parameter for the Classifier.getClassificationsForLine is now required

See Pull Request #2051 for more details.

TextChange.start and TextChange.length became properties instead of methods.

SourceFile.getLineAndCharacterFromPosition

SourceFile.getLineAndCharacterFromPosition became SourceFile.getLineAndCharacterOfPosition

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

We did some cleanup to the public interfaces, here is the full list of changes:

typescript_internal.d.ts and typescriptServices_internal.d.ts have been removed

The two files exposed helpers in the past that were not part of the supported TypeScript API. If you were using any of these APIs please file an issue to re-expose them; requests for exposing helper APIs will be triaged on a case-by-case basis.

For more information please see the full change.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4