Issue 1:
With the support now for .tsx and .ts files, it is possible to have multiple input files with the same root name in a compilation (i.e. file1.ts and file1.tsx). Both of these may try to generate the same output file on compilation (i.e. file1.js), and only one will win. If/when more extensions for input (or output) files are added, this will exacerbate the problem.

TypeScript should detect collisions on emitted files and error. (Ideally for resilience and future proofing, it should also detect if an emitted file would overwrite one of the input files).

Issue 2:
Hi, I realize that this has been asked on Stackoverflow before and Ryan gave a short answer, but I would really like to see this discussed more, since I believe this could be a huge time and ressource saver if it was implemented differently:

I am trying to write a compact typescript definition file, but I am having troubles doing so for a larger project.

My project has lots of interfaces that are implemented by a number of classes.

From what I can see I always need to re"implement"/redeclare the methods of the interfaces in the classes like so:

declare module someModule {

interface InterfaceOne {
/**
* Some lengthy description
*/
someStuff():any;
/**
* Some lengthy description
*/
moreStuff():any;
}

class OneClass implements InterfaceOne {
/**
* Some lengthy description
*/
someStuff():any;
/**
* Some lengthy description
*/
moreStuff():any;
/**
* Even more description
*/
classStuff(): any;
}

class TwoClass implements InterfaceOne {
/**
* Some lengthy description
*/
someStuff():any;
/**
* Some lengthy description
*/
moreStuff():any;
/**
* Even more description
*/
classStuff(): any;
}
}

If I leave out the someStuff and moreStuff declarations from the interfaces in the class declarations

I get this error:

error TS2137: Class TwoClass declares interface InterfaceOne but does not implement it:

So I always need to copy all of the declarations to each and every class that implements the interface.

In his answer to the similar question Ryan wrote this:

Let's say you didn't have to write out the interface members:

class Base { }
class Derived extends Base { }

interface Foo {
method(t: number): Base;
}

declare class FooImpl1 implements Foo {
// Empty
}

declare class FooImpl2 implements Foo {
public method(): Derived;
}

Is FooImpl2 trying to declare an additional overload of method, or is FooImpl2 implementing

method using a signature that takes fewer parameters and returns a more derived type? Either

would be a valid interpretation. You'd have to make rules for all sorts of cases like this so the

programmer could specify what they actually meant, making the language less predictable.

I don't understand his arguments:

First: for the vast majority of cases the //Empty case is the case that is totally _un_ambiguous: I have a class that implements Foo and thus I can call all methods from Foo, why do I need to redeclare all of them?

Second: It's the same thing with classes, too, and there the existing rules seem to suffice: If I extend a class (in a definition .d.ts file) I don't have to reenumerate all the base type members either:

class Base {
baseMethod():any;
}

class Derived extends Base {
derivedMethod():any;
}

class Foo {
public method(t: number): Base;
}

class FooImpl1 extends Foo {
// Empty - works! why not for interfaces?
}

class FooImpl2 extends Foo {
public method(): Derived;
public method(t: number): Base; // need to redeclare in case of overload if I want to use that method!
}

So why should this not work for interfaces, too?

By the way I really don't understand why you cannot do the following if you leave out the redeclaration in the last line of FooImpl2 above:

new FooImpl2().method(2); // TS2081: Supplied parameters do not match any signature of call target. TS2087: Could not select overload for 'call' expression.

If FooImpl2 extends Foo, it must be possible to call method(t:number) from the base type and the method declared. After all it's all about library definition files (.d.ts) that declare how the library will behave, so the overload resolution happens at runtime and if multiple members are declared, then all of them should work and be available, shouldn't they?

So back to the original question: Why can't implements SomeInterface behave like extends SomeClass in .d.ts declaration files? This would save us so much duplicated declarations and documentation, decrease the d.ts file size and speed up compilation and parsing, wouldn't it?

Edit 2015-10-31: I had accidentally written that my desired way of writing the declaration would be "ambiguous" in the most common case - of course I meant "_un_ambiguous", otherwise this would all make no sense.