typescript Issue Tracker Rss Feed

Edited Unassigned: Copy-paste annoyance in Visual Studio [1036]

nabog — Sun, 19 May 2013 10:12:19 GMT

Reopened Unassigned: Copy-paste annoyance in Visual Studio [1036]

nabog — Sun, 19 May 2013 10:12:13 GMT

Commented Unassigned: Copy-paste annoyance in Visual Studio [1036]

nabog — Sun, 19 May 2013 10:12:10 GMT

Hi, to reproduce:

* Enter the following bit of text in any TypeScript file in Visual Studio.

```
// Foo/Bar/Baz
// Foo-Bar-Baz
// Foo+=Bar+=Baz
```

* Copy any single line of text, omitting the comment slash, e.g. copy "Foo/Bar/Baz" into the clipboard.

* Paste it back into the TypeScript file.

* The pasted text is rendered with code formatting:

```
Foo{space}/{space}Bar{space}/{space}Baz
```

Text pasted from the clipboard should not undergo any formatting.

This is the behaviour in other code files in Visual Studio, such as C#.
Comments: I believe the "Automatically format on paste" behaviour in the TypeScript editor is a bit faulty. I already have this checked for C# but the C# edit does not have the behaviour that I described in my original post. I think the C# editor is clever enough to only attempt to format pasted text that was already formatted when it was copied to the clipboard. If I uncheck the TypeScript option "Format on paste" then nothing gets formatted on paste, for example copying and pasting a method within a class leads to unformatted code. I would like to keep "Format on paste" on, but that shouldn't attempt to format previously unformatted text pasted from the clipboard.

Commented Issue: Invalid sourcemap when combining 2 files [1032]

Naav — Sat, 18 May 2013 14:28:49 GMT

Commented Issue: Invalid sourcemap when combining 2 files [1032]

Naav — Sat, 18 May 2013 09:43:27 GMT

Created from a comment in this issue: https://typescript.codeplex.com/workitem/772

TypeScript compiler creates an invalid sourcemap when combining the following 2 files

@animal.ts

````
module animals {

export class Animal {
private killed;

kill() {
this.killed = true;
}
}

}

````
@dog.ts

````
module animals {

class Dog extends Animal {
bark() {
console.log('bark')
}
}

}
````

validate using source-map module in node

````
var SourceMapConsumer = require('source-map').SourceMapConsumer;
new SourceMapConsumer(require('fs').readFileSync('bug.js.map', 'utf8'));
````
Comments: It seems this problem comes from the fact that the TypeScript compiler uses a list to store mapping names (therefore allowing duplicates): ["animals","animals.Animal","animals.Animal.constructor","animals.Animal.kill","animals","animals.Dog","animals.Dog.constructor","animals.Dog.bark"] SourceMapConsumer uses a set, so all duplicate names disappear, leading to an incorrect offset during mapping name translation. I'll submit a patch if I can figure out how this Codeplex thing works.

Created Unassigned: Static generic methods are not supported. [1052]

DRubino — Sat, 18 May 2013 04:32:29 GMT

Static generic methods don't seem to be supported. This would be an incredibly useful feature to me.

```
//Compiles fine
class MyClass {
myGenericMethod<U>(input: U): void { }
}

//Compiles fine
class MyGenericClass<T> {
myGenericMethod<U>(input: U): void { }
}

//Does not compile
class MyStaticClass {
static myGenericMethod<U>(input: U): void { }
}

//Does not compile
class MyStaticGenericClass<T> {
static myGenericMethod<U>(input: U): void { }
}
```

Unrelated to the issue, but you fixed one of my other issues. How can I install the latest build of TypeScript 0.9 alpha? I'd love to get my hands on the most recent changes.

Best,
Doug Rubino

Closed Issue: Store certification fails with TS-generated files [531]

billti — Sat, 18 May 2013 01:10:16 GMT

The current version of TypeScript does not output the generated javascript/map files as UTF-8 with the byte order mark.

Store certification for WinJS apps requires that the js files are UTF-8 with BOM. Apps without will fail certification.

This is a blocker for Store apps that want to use TypeScript.
Comments: This should be fixed with https://typescript.codeplex.com/SourceControl/changeset/307e63d6b2bdad42cf3e15ac8a84af8851cdb783 . Basically, if any input file has a BOM, then we'll emit the generated code files with a BOM also.

Closed Issue: Generic interface extension fails for 0.9 alpha [1002]

billti — Sat, 18 May 2013 00:18:07 GMT

To whom it may concern,

Thank you for considering my bug report. I love TypeScript and was eager to try out the new generics support. While trying to extend the interface for Array<T>, I think I uncovered a more general bug.

The two code snippets below represent analogous ways to extend an interface. The first example does not compile and the second does. The only difference is that the first has a generic parameter.

My sense is that this feature should be supported.

Thank you.

Best,
Doug

```
//Does not compile
interface IA<T> { x: string }
interface IB<T> { y: string }
interface IB<T> extends IA<T> {}
class B implements IB<number> {
x: string;
y: string;
}

//Does compile
interface IC { x: string }
interface ID { y: string }
interface ID extends IC {}
class C implements IC {
x: string;
y: string;
}

```

Comments: This should be fixed now as of http://typescript.codeplex.com/SourceControl/changeset/a74df8e6f44f048a8eba363b066c5cfb14f17604 . Thanks!

Commented Unassigned: intellisense gone whenever writing something in a try catch block. [1048]

zijianhuang — Fri, 17 May 2013 23:20:32 GMT

I am using 0.9 preview. However, whenever I write something in a try catch block, intellisense gone completely in the TS file, while others TS file are still having intellisense, as long as I don't write anything inside the try catch block.

Creating a new try catch block with empty content will also trigger the same problem.

Reloading the file or the solution won't fix the problem.

The only way to restore intellisense is to restart VS IDE.

Now I have to be very careful and write a try catch block in Programmer's Notepad and then copy/paste back to VS IDE. Odd and troublesome.

:(
Comments: Even a fresh app.ts created by the IDE suffers the same problem as soon as I add a try catch block. I had 0.8.3.1, and uninstalled it, then installed 0.9. I guess the clean up process of the uninstallation is not clean enough It might be just me, and I had a silly work around now. Hopefully next release will be better.

Closed Unassigned: intellisense gone whenever writing something in a try catch block. [1048]

paulb — Fri, 17 May 2013 22:34:47 GMT

I am using 0.9 preview. However, whenever I write something in a try catch block, intellisense gone completely in the TS file, while others TS file are still having intellisense, as long as I don't write anything inside the try catch block.

Creating a new try catch block with empty content will also trigger the same problem.

Reloading the file or the solution won't fix the problem.

The only way to restore intellisense is to restart VS IDE.

Now I have to be very careful and write a try catch block in Programmer's Notepad and then copy/paste back to VS IDE. Odd and troublesome.

:(
Comments: I'm not able to reproduce this using the latest bits from the development branch. Does it happen in projects of all sizes or only large projects. Thanks

Commented Unassigned: public and private method with same name but no compiler error [1051]

K2P2 — Fri, 17 May 2013 19:06:42 GMT

Commented Unassigned: Preserve comments should not emit /// references [995]

danquirk — Fri, 17 May 2013 18:04:26 GMT

Hi Guys,

I've got a problem with TypeScripts "preserve comments" mechanism.

In my existing project I'm using Cassette to serve up my JavaScript files. If you haven't heard about Cassette you can read up on it here: http://getcassette.net

In particular I'm taking advantage of the ability to get Cassette to serve scripts in dependency order through the use of reference comments at the top of JavaScript files that look like this:

// @reference other.js

or this:

/// <reference path="other.js" />

(nb if interested you can find more details on how that works here: http://getcassette.net/documentation/v1/AssetReferences )

Because I want to continue to take advantage of this feature of Cassette working with the JavaScript generated by the TypeScript compiler I was intending to enable the "preserve comments" option. This would work fine with me making use of the "// @reference other.js" style references in my TypeScript. However, to my frustration the typing file comments are * __also__ * being preserved. This seems a little strange to me since these aren't strictly speaking comments, more compiler directives masquerading as comments.

So my JavaScript ends up with references to the typings files like this:

/// <reference path="jquery.d.ts" />

Just to demonstrate, TypeScript like this:

```
// @reference jQuery-1.8.2.js
/// <reference path="jquery.d.ts" />

// Module
module Shapes {

// Class
export class Point implements IPoint {
// Constructor
constructor (public x: number, public y: number) { }

// Instance member
getDist() { return Math.sqrt(this.x * this.x + this.y * this.y); }

// Static member
static origin = new Point(0, 0);
}

}

// Interface
interface IPoint {
getDist(): number;
}

// Local variables
var p: IPoint = new Shapes.Point(3, 4);
var dist = p.getDist();
```
Will generate JavaScript like this:

```
// @reference jQuery-1.8.2.js
/// <reference path="jquery.d.ts" />
// Module
var Shapes;
(function (Shapes) {
// Class
var Point = (function () {
// Constructor
function Point(x, y) {
this.x = x;
this.y = y;
}
Point.prototype.getDist = // Instance member
function () {
return Math.sqrt(this.x * this.x + this.y * this.y);
};
Point.origin = new Point(0, 0);
return Point;
})();
Shapes.Point = Point;
})(Shapes || (Shapes = {}));
// Local variables
var p = new Shapes.Point(3, 4);
var dist = p.getDist();
//@ sourceMappingURL=file1.js.map

```

As you can see this has the unfortunate side effect of serving up the typing files which will in turn make Cassette serve up the TypeScript typings files with the JavaScript. And that stops me from making use of TypeScript in the way I would hope.

Would it be possible to introduce more fine grained control over what comments should be preserved?

Perhaps it would be possible to include a block syntax that, if present would indicate that a set of comments should __not__ be preserved? Maybe something as simple as this would suffice?:

```
//

```

Alternatively, would it be possible to introduce a compiler option which preserved comments but not comments that are actually typing references? Either would work for me...
Comments: Thanks for the additional info. I believe in general we would aim to expose any public compiler flags with project support (whether that means in the project file and/or project properties UI or something else). No need for a new issue, we use these to track suggestions as well as bugs.

Closed Unassigned: Terminating curling brace not required [1049]

paulb — Fri, 17 May 2013 17:01:29 GMT

The compiler (0.8.0) does not complain about this piece of code:

class xyz {
public fun() {
}

Notice the missing terminating }

Comments: Thanks for reporting this has been fixed in later builds.

Closed Unassigned: Compilation with --out to only add files that are referenced in the code [1050]

paulb — Fri, 17 May 2013 17:00:45 GMT

In some languages (e.g. ActionScript3 where a lot of the new typescript devs are coming from) imports are the equivalent of typescripts ///<reference path='typescript.ts' /> references.
The --out parameter ist the equivalent of an swf compilation (put everything in one file)

One major advantage of the AS3 Compiler is, that it knows which classes are really used and only include these classes/files into the final package. It would be great if typescript had the same capabilities as i would make writing typescript for the browser a lot easier.
Comments: This is by design. Consider the scenario in a web-browser where you load several js files, each can reference classes in each other and we don't have a way to determine which are used and which are not. The second issue you've reported about the ordering of classes. Can you open a new bug for that with a small repro. Thanks!

Closed Unassigned: public and private method with same name but no compiler error [1051]

paulb — Fri, 17 May 2013 16:53:55 GMT

Just coming to TypeScript and CodePlex.

I converted a file that had two functions in it (notice the underscore):

_sendJsonAsync = function ( url, json ) and
sendJsonAsync = function ( url, json )

In typescript I changed this to:

private sendJsonAsync = function ( url, json ) and
public sendJsonAsync = function ( url, json )

Since they were far apart in the file I couldn't see the obvious __but the typescript compiler didn't warn or produce an error either__ which caused my app to stop working because of "infinite recursion".

Anyway I changed them back to the first naming convention in typescript:

private _sendJsonAsync = function ( url, json ) and
public sendJsonAsync = function ( url, json )

Comments: Thanks for reporting this. I tried this in the 0.9 version of the compiler in the develop branch and get the error as expected using the following snippet: ```` class C { private sendJsonAsync = function (url, json) { } public sendJsonAsync = function (url, json) { } } ```` Is this what you tried? Can you post a more complete sample if you did something different. Thanks!

Edited Unassigned: public and private method with same name but no compiler error [1051]

K2P2 — Fri, 17 May 2013 16:45:24 GMT

Created Unassigned: public and private member with same name but no compiler error [1051]

K2P2 — Fri, 17 May 2013 16:27:57 GMT

Closed Unassigned: module imports get lost [1038]

billti — Fri, 17 May 2013 15:08:27 GMT

* use the latest from develop (7682fa4)
* compile the snippet below

```
import foo = module('super');

function bar(f) {
return true;
}

console.log(bar(foo));
```

* see that the generated code misses the import and will cause an error

```

function bar(f) {
return true;
}

console.log(bar(foo));

```

Comments: This is the same issue as https://typescript.codeplex.com/workitem/1029 . We're looking into it.

Commented Feature: Support non-code AMD modules [1046]

fsoikin — Fri, 17 May 2013 14:15:53 GMT

Here is a peculiar exercise that I have to go through every time I need my module to depend on something that is not code, such as a template or a stylesheet:

```
// fragment (1)
declare module 'text!./Templates/Template.html' { }
import template = module( 'text!./Templates/Template.html' );

```

And then:

```
// fragment (2)
$(element).html( <string>template );
ko.applyBindings( this, element );
```

The first solution that jumps to mind is not to use TypeScript module syntax at all, but instead wrap fragment __(2)__ in a straight __require()__ call, like this:

```
// fragment (3)
require( ['text!./Templates/Template.html'], (template: string) => {
$(element).html( <string>template );
ko.applyBindings( this, element );
});
```

But there are two alternative problems with this approach: it will either (a) introduce an undesirable "flickering" effect as components load and show themselves one by one, or (b) create a ripple effect forcing me to make my whole program asynchronous, which would seriously damage the whole point of using AMD loader in the first place and make the code a lot less maintainable, not to mention the obvious difficulties of combining Knockout-style data bindings with async architecture.

I want the "clean" solution, that is __loading my whole module dependency graph as a single logical operation__.

I've also tried experimenting with the module import syntax itself to put this ugly business away into a function or something, but no luck: the TypeScript spec explicitly states that module id should be a string literal, no way around it.

So a possible solution I can envision could be something like this:

```
// fragment (4)
import template = content( 'text!./Templates/Template.html' ): string;

// and later:
$(element).html( template );
```

which would generate JS code in exactly the same way it does now:

```
// fragment (5)
require(["require", "exports", "text!./Templates/Template.html"], function(require, exports, __template__) {
var template = __template__;

// and later:
$(element).html( template );
}
```

That is, no code generator changes necessary.
Comments: Oh, missed that somehow. Well, if I need to specify it in two places anyway, that doesn't do any good, I'm afraid :-( Thank you for pointing out, though.

Commented Unassigned: Compilation with --out to only add files that are referenced in the code [1050]

TobiasHei — Fri, 17 May 2013 10:35:35 GMT

In some languages (e.g. ActionScript3 where a lot of the new typescript devs are coming from) imports are the equivalent of typescripts ///<reference path='typescript.ts' /> references.
The --out parameter ist the equivalent of an swf compilation (put everything in one file)

One major advantage of the AS3 Compiler is, that it knows which classes are really used and only include these classes/files into the final package. It would be great if typescript had the same capabilities as i would make writing typescript for the browser a lot easier.
Comments: It would also be good if Typescript could put the referenced files in the right "order" as parent classes must be defined prior the child classes in Typescript