There is such a thing as a "library". For example, in Java it is .jar file, in ActionScript - .swc file and so on.
In order to connect library/libraries to Java/ActionScript project I need to specify instructions for compiler - where compiler should to looking for libraries.
And I do not need to specify the relative path to the library file in each source file which use library.

It would be great to be able to give instructions to the compiler and do not specify relative paths relative to the current source file.
At least, this applies to *.d.ts files.
And if it be possible to create a "library" from .ts files, it will generally be fine :)

Thanks for the suggestion.

TypeScript doesn't currently have a project system per se, yet, which I think would help with what you're suggesting, by giving some defaults to where things like .d.ts files are found. 

As for the bundling, TypeScript compiles down to JavaScript, so if there are ways to bundle JS, you should get that "for free"

>As for the bundling, TypeScript compiles down to JavaScript

Yes. I understand this. But I mean some other. Because ActionScript closest for me so I will explain using its terms. There is opportunity to create .swc library file (like .jar file for Java). I can use this .swc file when write code and use built-in classes in my new code. I.e. I can create some library, combine its code into single file and use this single file in several projects. And I can be sure that I use same code in all projects. Also, if I make changes in the library, then I can create a new version of "library" file and I will have to update single file. Yes, I understand that I can just copy .ts files and to have same result. But using of "single library file" is more convenient. Second advantage of library is that it contains already compiled code. I.e. compiler no need to compile it again. In result time of compiling is less. Third advantage of library (vs JavaScript library which will be included into HTML page) is that result application contains only required code from library and not all library.

Theoretically it is possible to find other advantages of such way. Basically, suggestion about "library" was just fantasy about possible solution. For me more important to have ability to specify "source" paths for compiler in order to not write something like

/// <reference path="../../../../libs/google.maps.d.ts" />

in each .ts file which use Google Maps library

kostiknoir wrote:

>Yes, I understand that I can just copy .ts files and to have same result. But using of "single library file" is more convenient.

This is an excellent suggestion - one that I've been thinking about myself:

1. When a TypeScript project is built, it creates ".js" files in the bin directory - one for each corresponding ".ts" file in the project.
2. It also creates a single <MyProject>.d.ts file in the bin directory, containing all the definitions across all ".ts" files in the project.
3. When a new TypeScript project is created, it should be possible to right-click on the project and go "Add Reference" and select any existing TypeScript project in the solution, or browse to and add a reference to a "d.ts" file.
4. Once a TypeScript project is referenced via this mechanism, then all types in the referenced project become available to the referrer.

Further points for consideration

• It is probably important to produce multiple JavaScript (".js") files as output, rather than a single file, because of AMD reasons. Project settings could provide an option for producing a single ".js" file if required.
• When the project is built in release mode the output is minified.
• There is no longer any need for <reference> includes, which is rather an Achilles Heel at the moment, since we are relying on an XML comment to carry out important work.

Another alternative is to produce a single packaged output file (as outlined by Kostiknoir and also in the link above), which contains all the ".js" files,  the "d.ts" file, as well as any HTML and CSS files in the project. This new output file could not only be used in other TypeScript projects, but also web projects such as ASP.Net Web Applications.

Noel

>It is probably important to produce multiple JavaScript (".js") files as output, rather than a single file

1) AMD idea is good but it is, in my opinion, it is too idealistic idea (when each module loaded as separate file). Reason very simple - total time of loading of all files. So I'm doubt that somebody deploy project which contains, for example, 100 not concatenated JS files.

So for me AMD is just way not write:

var myLib = myLib || {};

var myLib.view = myLib.view || {};

and so on.

I'm just place files in appropriate directories and "build system/compiler" do all job for me.

2) >because of AMD reasons

Now, I use such way for TypeScript based projects: write TypeScript code => call TypeScript compiler (with --module amd) => in result I get separated JS files => pass these files to r.js => in result I have minified and combined single release .js file

Everything this occurs with help ANT.

If to look into such release .js file then there are constructions like:

define("myApp/view/MyListView",["require","exports"],function(e,t){var n=function().........),

define("myApp/view/MyOtherListView",["require","exports"],function(e,t){var n=function().........),

and so on.

I.e. r.js create named AMD modules.

Such pattern "file path equals class namespace" exists at least in Java and ActionScript. And when I open directory myApp/views and see there files View1.as, View2.as then I sure that file View1.as contains myApp.views.View1 class. And so on.

Similar thing make brunch.io.

==========

If to continue to dream about TypeScript "library" then there is possible such way:

compile TypeScript library mean that TypeScript compiler create "library" files which contains something like:

var classes: any = {};
classes["myApp/view/ListView"] = 'define("myApp/view/MyListView",["require","exports"],function(e,t){var n=function().........)';
classes["myApp/view/MyOtherListView"] = 'define("myApp/view/MyOtherListView",["require","exports"],function(e,t){var n=function().........)';
.... 
// and so on

also such files should contains definitions (like in *.d.ts files) for inner classes/modules.

In result in my code I will just import "myApp/view/ListView" and use it,. And my application release file will contains only code related to "myApp/view/ListView" and will not contains code of all library.

But in order to implement this, TypeScript compiler should support "source path(s)".

Also it would be good to have ability to "exclude" some code from app release file.

>as well as any HTML and CSS files in the project

Mmm.. :) I'm doubt. Yes. I'm agree that this is cool ability (like single swf file with all resources) but it is, in my opinion,  beyond the scope of TypeScript.

=============

By the way, for admins: rich text editor have not "clear format" button