Issue 1:
never and void assignability

class Base {
method() {
throw new Error("Not Implemented");
}
}

class Derived extends Base {
method() {
throw new Error("Not Implemented");
}
}

Allowing duplicate identifiers across declarations (#8675, #8696)

Introduced stack into the Error interface.

We report duplicate identifier errors, even if the types are the same.

These augmentations are the same.

👍, let's allow this.

Need to do checks for same modifiers (abstract, readonly, visibility).

super issues

Subclassing without calling super (#7285)

class MyElement extends HTMLElement {
constructor() {
return document.createElement('my-element');
}
}

What is the behavior of the example?

Returns something that is an instanceof an HTMLElement...but not MyElement?

This is extremely odd. You aren't returning the instance you're constructing.

MyElement won't be in your prototype chain, you won't get the appropriate methods.

But this is an ES2015 issue.

Unclear what we do about this.

Using return value of super calls (#7574)

class Foo {
x: number;

constructor() {
return {
x: 1,
};
}
}

class Bar extends Foo {
y: number;

constructor() {
super();
this.y = 2;
}
}

let o = new Bar();
console.assert(o.x === 1 && o.y === 2);

The actual behavior of this is that the assertion should not fail.

In reality, this takes on the value of { x: 1 } in Bar's constructor, since Foo returned it from its constructor.

Incurs an overhead.

This requires some wonky code to enable this scenario.

Everyone has to pay the price regardless of whether they use it.

Could we just do something like _this = _super.call(this) || this instead of a helper?

Seems like spec says behavior for primitives causes issues.

This is a very niche case.

We'd also have to return _this to maintain _this value.

"If we had attributes, people could hint the correct thing."

We need to think about this more.

This seems to be a large change for a somewhat niche scenario, but we should better understand the users of it.

Super as the first statement (#8277)

Perhaps we could fake this with definite assignment analysis?

Start with a "poison" type, super(/*...*/) gives you some sort of "antidote" type (any other type?), check if you still end up with the poisoned type.

People an always cheat by putting code in an arrow function.

Not a big deal, you're really trying at that point.

--target ES5 --module ES6

Emit in ES5, entirely except for module

Useful for Rollup.

Becoming an increasingly common tool.

Why do we have to provide this functionality? How does Babel do this?

There's a Babel plugin.

Well there's a TypeScript plugin too, but there are some issues with that.

Let's just try it out and see how it works out.

Switch to not type-check .d.ts files

Parse/bind .d.ts files.

Don't check them unless entities are referenced from those .d.ts files.

This means you might miss errors across files.

But would be much faster.

Angular and NativeScript both have said they'd like it.

Have to think of a name for this.

Issue 2:
Hi there!

I am writing a lot of code in an environment where JavaScript and TypeScript freely interact with each other. One thing that we continue to run into is where we would write a function in TypeScript, say:

export function add(x: number, y: number): number {
return x + y;
}

This function is callable from JavaScript, where we're allowed to do things like:

add('abc', undefined)

This has lead us to introduce type checks for all exported functions in TypeScript, although they really feel verbose in a typed language.

export function add(x: number, y: number): number {
if (typeof x !== 'number' || typeof y !== 'number') {
throw new TypeError('x and y need to be numbers');
}
return x + y;
}

My idea is to provide an optional flag, say --insertRuntimeTypeChecks, that makes the compiler insert these kinds of checks for function arguments.

The feature will probably be a bit more complicated when thinking about structural types, etc., especially in interplay with classes (it is my understanding that classes are type-checked structurally, not nominally, is that correct?).

But even having it only for primitive types (checking for object, string, number, etc.) could provide a lot of benefits for those of us who write code that interacts with JavaScript, especially should #7140 land, to spare us from manually writing if (x === null) ....

I'd be interested in giving implementing this a shot, if there's interest from the maintainers.