We should just link to handbook content. When both the wiki and handbook are in flux, keeping them in sync can be a bit of a pain.

I'd like to be able to edit the wiki.

I'm seeing this error when going to https://github.com/Microsoft/TypeScript/wiki/What's-new-in-TypeScript

Hello guys,

First of all; thank you for the great examples on your website :) They really help me with some work I'm doing.

When looking to some code examples (like here: https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API) I have a hard time reading it, since my mouse doesn't have a horizontal scroll option. Can you introduce a rule for max 80 width in code examples? I'm willing to help realising this, just say the word :)

Guido

There's a typo in https://github.com/microsoft/TypeScript/wiki/Performance#using-type-annotations, where the expanding thing hides the rest of the page rather than just one comment.

Should be a easy 2-minute fix for someone with wiki write privileges.

The now very old still unmerged PR #225 has been very useful in creating an incrementally building program but now I want to set up an incrementally building program that also watches for changes so I can avoid the long file system scan that happens when I create the incremental program.

Unfortunately I don't understand how to combine the different host, program and configuration objects to achieve this.

Hello.
I have this sources

import * as React from 'react';

export interface MyComponentProps{
    prop1: number;
    prop2: string;
}
/**
* descriptions for component
*/
export  class MyComponent extends React.Component<MyComponentProps,{}>{
   render(){
     return(
       <div>
       </div>
     );
   }
}

I use docgen from this wiki example

this is output

[
    {
        "name": "MyComponent",
        "documentation": "descriptions for component",
        "type": "typeof MyComponent",
        "constructors": [
            {
                "paramters": [],
                "returnType": "MyComponent",
                "documentation": ""
            }
        ]
    }
]

I want to extend this output by type of first generic passed to react.component.

How to extract generic type passed to parent class?
Thank you!

Under the this section in 2.0 there is a line that says the following:

That means that this is of type Deck now, not any, so --noImplicitThis will not cause any errors.

Where is Deck even mentioned? It seems out of place.

Node.js v14 will become LTS on 2020-10-27, so it's worth updating https://github.com/microsoft/TypeScript/wiki/Node-Target-Mapping

https://github.com/microsoft/TypeScript-wiki/blob/master/Breaking-Changes.md#contextual-return-types-flow-in-as-contextual-argument-types

In the documentation it lists the "broken" version as:

function isEven(prom: Promise<number>): Promise<{ success: boolean }> {
    return prom.then<{success: boolean}>((x) => {
        return x % 2 === 0 ?
            { success: true } :
            Promise.resolve({ success: false });
    });
}

The work around is listed as:

function isEven(prom: Promise<number>): Promise<{ success: boolean }> {
    //               vvvvvvvvvvvvvvvvvv
    return prom.then<{success: boolean}>((x) => {
           return x % 2 === 0 ?
            { success: true } :
            Promise.resolve({ success: false });
    });
}

Both versions of the code are the same.

2 links on the home page are broken:

- [Debugging TypeScript problems](./debugging)
- [Wanting to contribute to the TypeScript codebase or to understand the compiler](./learn-the-compiler)

Those links are:

• https://github.com/microsoft/TypeScript/wiki/debugging
• https://github.com/microsoft/TypeScript/wiki/learn-the-compiler

At the time of writing this, JSDoc-support-in-JavaScript.md appears to be out of date. The page explicitly states that the @typedef tag is not currently supported, but support for @typedef appears to have been added prior to version 2.0. microsoft/TypeScript#7758

I would update the page myself, but I'm not familiar with what tags are currently supported, and I don't know where to look.

Roadmap does not mention version 3.8.

I think it did at a moment in time but it went missing. I mentioned this here as well and I'm pretty sure I saw 3.8 on the roadmap at one time after that.

On the wiki page:
https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API

The documentation is for 1.5:
First you'll need to install TypeScript >=1.5 from npm.

Definitions Raw File

The definitions file is pointing to the 1.4 on the line:
Going directly to the source on our repository.

This links to:
https://github.com/Microsoft/TypeScript/blob/release-1.4/bin/typescript.d.ts

It should link to:
https://github.com/Microsoft/TypeScript/blob/v1.5.0-alpha/bin/typescript.d.ts

Definitions Installer

Also the command:
tsd query typescript --action install

Installs the 1.4 definitions files

The wiki page for What's new in TypeScript is now gone/moved as it got too big for Github to render(#226). That makes sense, but now all the bazillion links (like this one for readonly tuples) I and others have added to answers/comments on StackOverflow questions are broken. Would it be possible for the wiki page to be edited to preserve the existing permalinks? I mean, even if the old link points to a nothing but another link to the same content hosted elsewhere (e.g., pointing to an old revision) so that the user has to click twice, it's better than just the current "this page has moved". It would hopefully be small enough to actually render anyway.

Thoughts? I would make a PR but I'm not sure if the code here is where the actual wiki code comes from (it seems out of date?).

I've been recently looking at parsing --diagnostics output to report to out metrics service so that we can monitor compile times and while attempting to normalize values to a common unit (e.g. durations to seconds and memory used to MB), I've noticed that the docs are not very clear about the metric definitions and their respective units.

I would love if the docs specified what are the possible units that may be reported for each metric. For instance, can Total time be reported in milliseconds or even minutes right now? I see that memory used is reported as K, I assume that is kilobytes, but I'm not sure.

Less importantly, but in a similar vein, the duration timings (parse, bind, check, emit and total time) do not specify if these metrics are reported in wall time or CPU time. (it doesnt make much difference for our purposes, but it would be good to know how the metric may be affected).

If someone can point me to the relevant files where these metrics are measured, I would happy to take a stab at opening a PR :)

Thanks so much!

https://github.com/Microsoft/TypeScript/wiki/FAQ#can-i-make-a-type-alias-nominal

Would be better to use my branding formulation which is more self-documenting and less likely to produce an accidental structural collision.

this is what im having in mind:

var config = { // this is generated on the fly ... or JSON.parse(readFileAsText('tsConfig.json'))
    "compilerOptions": {
        "target": "es6",
        "module": "commonjs",
        "outDir": "./lib",
        "jsx": "react",
    },
    "compileOnSave": false,
    "include": ["src"],
    "exclude": ["lib"]
}

var emitResult = tsc.compileByConfig(config); // this line is what im missing ..

currently i have no idea, how to resolve all files that will be compiled...

The Example provided for Creating and Printing a Typescript AST section in the Using-the-Compiler-API.md uses Typescript Complier APIs which are deprecated and need to be updated.

This section:
https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in-TypeScript#await-completions-on-promises

This is what it shows up as for me in Firefox and Edge Canary:

From the Typescript web site ( https://www.typescriptlang.org/docs/handbook/functions.html ) ;

let myAdd: (x: number, y: number) => number =
    function(x: number, y: number): number { return x + y; };

....but an arrow function is not functionally the same as a "function" function - they are not the same (type of) thing.

Extending native object has been documented in Breaking Changes section. But for new comers it seems not as discoverable as FAQ.

We already have a lot of duplicate questions on issue listing which qualifies extending native object as Frequently Asked.

Would be happy to submit a PR for it.

I would like to create a PR fixing a typo and trying to make the What's new better but it seems like this repo is not up to date with what I can see in the actual Typescript repo's wiki.

Do we have a release schedule for the updates to this repo?

From @DeanB2015's issue at microsoft/TypeScript#5095:

https://github.com/Microsoft/TypeScript/wiki/tsconfig.json has great information. Would be nice to see a d.ts in the files element in `Using the "files" property example. It would demonstrate how d.ts files can be used instead of reference path="angular2/angular2.d.ts" /> ???

Example:

"typings/tsd.d.ts"
"angular2/angular2.d.ts"
.....

Hey, I want to fix a typo (paragma) in https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in-TypeScript#typescript-28, but this repository seems to be several months old without a change and the branch names do not indicate there is a different working branch from master, all of them seem to be branches for specific things.

The file I am interested in, What's-new-in-TypeScript.md is stuck at TS 2.6 whereas the link above is about 2.8. Where is the up to date file?

Can the Want to contribute to this Wiki? be redone so that it takes you to the actual source file and not just the wiki repo?

On Specifying the type of this for functions section in What's-new-in-TypeScript.md file, there are extra text under the first example of the section. The extra text is this:

That means that this is of type Deck now, not any, so --noImplicitThis will not cause any errors.

This text doesn't appear on the wiki's page of TypeScript Repo.

Just before the advanced section of the Performance-Tracing page there is a link to the Performance page.

The current link is - https://github.com/microsoft/TypeScript-wiki/blob/main/Performance
I think the link is meant to be - https://github.com/microsoft/TypeScript-wiki/blob/main/Performance.md

Quick question - I know the process for updating the wikis is somewhat arduous, but do you do releases on a set schedule, or as needed?

I had added some documentation that I'd like to reference.

The roadmap page does not mention TypeScript version 3.6. Is it out of date? https://github.com/Microsoft/TypeScript-wiki/blob/master/Roadmap.md

This example gives type errors.

docGenerator.ts:65:53 - error TS2554: Expected 1 arguments, but got 0.
documentation: ts.displayPartsToString(symbol.getDocumentationComment()),

docGenerator.ts:99:36 - error TS2345: Argument of type 'Node' is not assignable to parameter of type 'Declaration'.
Property '_declarationBrand' is missing in type 'Node' but required in type 'Declaration'.
(ts.getCombinedModifierFlags(node) & ts.ModifierFlags.Export) !== 0 ||

Hello everyone, happy ny and holidays!

I've recently been using a lot of --generateTrace to debug some performance issues of our codebase (successfully). While doing so, I often used the chrome://tracing along with @amcasey's library (https://github.com/amcasey/ts-analyze-trace). Since I work on a continuous profiling product where we display our own flamegraphs, I've been quietly hoping to add support for tsc traces.

I couldn't find any information of the actual format used, but I suppose it follows https://docs.google.com/document/d/1CvAClvFfyA5R-PhYUmn5OOQtYMH4h6I0nSsKchNAySU/preview, could someone maybe confirm? In the similar vein, having an explanation of the types.json that is generated would also be ❤️

Thanks so much!

In the What's New... page, the TS 2.1 mapped types example for the Record type is broken with respect to its current definition due to the | number part in K extends string | number of the mapObject signature.

Original:

// For every properties K of type T, transform it to U
function mapObject<K extends string | number, T, U>(obj: Record<K, T>, f: (x: T) => U): Record<K, U>
const names = { foo: "hello", bar: "world", baz: "bye" };
const lengths = mapObject(names, s => s.length);  // { foo: number, bar: number, baz: number }

Corrected:

// For every properties K of type T, transform it to U
function mapObject<K extends string, T, U>(obj: Record<K, T>, f: (x: T) => U): Record<K, U>
const names = { foo: "hello", bar: "world", baz: "bye" };
const lengths = mapObject(names, s => s.length);  // { foo: number, bar: number, baz: number }

There are important files that Microsoft projects should all have that are not present in this repository. A pull request has been opened to add the missing file(s). When the pr is merged this issue will be closed automatically.

Microsoft teams can learn more about this effort and share feedback within the open source guidance available internally.

Merge this pull request

If I go to Special:Random page on Wikipedia right now and edit whatever I found, anyone is free to use the result under CC-BY-SA 3.0.

Under what terms is the TypeScript wiki content available?

We have been wanting to allow edit's to our wiki for Chocolatey, but we also want to "moderate" the submissions via pull requests. Having hunted around a bit, we hadn't found an "easy" way to do this, but it looks like you guys have.

Would it be possible for you to explain what you did to set this up so that this GitHub repo updates the wiki on the TypeScript GitHub Site. What process are you following?

Thanks in advance!

Hey @DanielRosenwasser,

I do hope you're well. First up, this is not directly an issue with the wiki at all, but I thought this was a good place to have a conversation about your wiki page on performance.

I was just talking with @dragomirtitian about me writing a blog post which would show how to take a few of the tips in here and apply them with ESLint; there’s ESLint rules out there that can help with this. Essentially the main ones of interest are:

• Prefer Interface over Type https://github.com/cartant/eslint-plugin-etc/blob/main/docs/rules/prefer-interface.md
• Enforce return types https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/explicit-function-return-type.md

Titian posed the (entirely helpful) question:

I'm sure these make difference.. By at what point.. 1K loc? 10Kloc? 100? If this is a concern for huge scale projects is it really worth it for smaller projects? I mean shaving off 0.2s in a build doesn't seem worth it if I have to maintain a type and an inferable return type.

This is a great question. And I have to state a personal stylistic preference fortypes over interfaces, as well as preferring return type inference. Much less noisy. But perf is royalty and style is secondary.

My own feeling is that if you want to go with these rules, it’s easier if you start with them at the beginning of a project that you expect to grow. As retro-fixing all of these in a codebase would not be fun!

Anyway, rambling done. I have two questions for you if have a moment:

1. Is it worth blogging to advocate that people use the above ESLint rules? Or is this potentially transient advice? Something that’s useful now but could change as the compiler evolves?

2. Do you have a feeling for what level of difference that following these standards can make? The answer will no doubt be "it depends", but I'm curious if you happen to have an idea for what the boundaries of success could look like here. So, is it possible to say something like "enforcing return types on functions has been observed to improve type checking performance by up to 40%", or "preferring interfaces over types has been observed to improve type checking performance by up to 20%"? Actually having an idea of the level of difference that could be made is a super helpful piece of info. (Essentially this is Titian's question 😄 )

I hope you don't mind me posting the question here. I did consider DMing you instead, but I thought I'd do a @swyx and "learn in public" 😄

https://github.com/Microsoft/TypeScript/wiki/Roadmap#35-may-2019

--noEmitOnError with --isolatedModules link

actual: https://github.com/microsoft/TypeScript/issues/310430
expected: https://github.com/microsoft/TypeScript/issues/31043

Dear TypeScript team, while reviewing your coding guidelines, I came across a list of Diagnostic Message Codes that describe all categories up to 7000. However, I noticed that there are error messages beyond 7000 (such as TS8020, TS17004 & TS18004). Do you have categories for these as well?