Adding support for named AMD modules.

[gisenberg]

This pull request adds support for named AMD modules and addresses the pain point of using TypeScript-generated AMD modules when anonymous modules and out-of-the-box bundlers (like r.js) are not an option.

This feature was previously discussed at https://typescript.codeplex.com/discussions/451454 and https://typescript.codeplex.com/workitem/285 where it was resolved as external/won't fix, but this feature was a big enough pain point in our recent adoption of TypeScript to warrant further investigation.

[sophiajt]

Thanks for the PR. We chatted a bit on Friday about it, and should be able to take a look shortly (a few of us have been out on a business trip this past week).

Thanks for being patient.

[mhegazy]

I do not like the use of comments to direct compilation, but i do not have a better solution either. implementation wise, I have no comments.

We will need a signed Contributor License Agreement (CLA) before proceeding. Download the agreement (Microsoft Contribution License Agreement.docx or Microsoft Contribution License Agreement.pdf), sign, scan, and email it back to cla@microsoft.com.

[gisenberg]

Thanks for reviewing! A signed CLA was sent over on 11/13.

My initial implementation hooked into export assignments (export = Foo : "moduleName"), but that was inconsistent with colon usage elsewhere in the language and had implications for folks using TSLint. I switched it over to a reference comment since that usage pattern was already being used for amd-dependencies and seemed to rock the boat the least.

[osbornm]

This does match the existing /// <amd_dependecy path='...'/> pattern

[sheetalkamat]

Report error for duplicate entry if !amdModuleName?
Add test case for same

[gisenberg]

Thanks for the feedback! I've updated the parser to treat multiple AMD module name declarations as an error condition and added a compiler test for that scenario.

[mhegazy]

thanks!

[osbornm]

[gisenberg]

Thanks!

[ca0v]

It strikes me that this would make a great compiler option as the first step in creating an AMD build. When tsc -out is specified with -m amd we automatically give names to these modules. The names are based on the location in the file system. I think --sourceRoot could identify an optional root folder is need be (not sure if that matters).

[gisenberg]

We also considered the compiler switch option, but updating the VS tooling wasn't something that could be addressed with a pull request.

[slaneyrw]

Just tried out this feature for the first time and found that the explicit name suppied in the "amd-module" directive was not then subsequently used when importing into another module. but kept the value used in the require statement.

/* app\classes\MyClass.ts */
/// <amd-module name="MyClass" />
class MyClass {
   ...
}

/* app\classes\MyClass.js */
define("MyClass", ["require", "exports"], function(require, exports) {
    ...
}

/* app\MyApp.ts */
import MyClass = require("classes/MyClass");
class MyApp {
    ...
}

/* app\MyApp.js */
define(["require", "exports", "classes/MyClass"], function(require, exports, MyClass) {
    ...
}

In this example I would have expected MyApp.js to use "MyClass" not "classes/MyClass" for the dependency name.

Is this expected ? If so is there any plans to "close the loop" ?

[mhegazy]

The /// is just used when emitting the file. it is more of an emitter directive if anything. We will need some clear language syntax that denoted a module name when it is different from a file name. possibly related to #17. Currently the assumption is that module names and file names are in sync, which does not really work with bundling scenarios, which i am amusing is what you are trying to do. We are looking into making module resolution work better with common AMD/CommonJS/SystemJs patterns (take a look at #2338).

[luboid]

Could this be realized

When in the module exists amd-module then need to be created .d.ts file, which will be located in well known place named_modules in the root directory of the project for example, then easy can be created reference to them from TypeScript and loading of JS files will be left to whichever module loader. If module name is "something1/somthig2/somthig3" then directory structure will be :

project
named_modules
something1
somthig2
somthig3.d.ts

only one catch here is, module do not need contain references to others with ./ or ../ - all references need to be typings