Support SystemJS module output.

[mikehaas763]

I do realize that the SystemJS loader can be used with AMD and CommonJS modules. Is there any interest in outputting directly to the system module format?

[chicoxyzzy]

+1. would like to see System loader implemented

[mikehaas763]

I've seen in the contributing guidelines that features need to be marked as "approved" before being accepted. I hope this one gets approved :) Just out of boredom I did fork and begin implementing SystemJS module output. You can check it out at https://github.com/mikehaas763/TypeScript/tree/systemjs

Please do leave me comments and suggestions on it.

There are several similarities to how AMD modules are created so I'm thinking I should find an abstraction for those similarities and use it from both module types.

[mikehaas763]

The actual function that emits the module format is mostly just a copy of the amd one at this point. I'm currently using https://github.com/ModuleLoader/es6-module-loader/wiki/System.register-Explained as a specification of sort for how I need to actually create the module format.

[mhegazy]

@mikehaas763 We are currently considering adding UMD (#2605) module support. so would be looking into systemjs as well.

@vladima has a change along the same lines as yours. it would be great if you can collaborate on getting systemjs PR ready.

[mikehaas763]

@vladima what change is it that you're working on?

@mhegazy It'd be nice if the current UMD spec had support for system modules!

[vladima]

In my branch https://github.com/Microsoft/TypeScript/tree/systemRegister I've added initial support for system emit, hoisting of variable\function declarations. Pending work: rewriting exports, adding tests

[mhegazy]

@mikehaas763 you can send PRs against @vladima's branch; i think this would be a good way to collaborate on this. we need to discuss the proposal in the language design meeting (which we usually have weekly). it would be great if we have a PR ready as well.

[niemyjski]

+1

[mikehaas763]

Looks like vladima has submitted his PR for this. So System.register modules should be coming soon! 😄

[mhegazy]

here is the PR: #2840

[jamiewinder]

Is this the only way to handle circular references in TypeScript at the moment? I understand that SystemJS supports circular references, but at the moment I often get errors in the class code if the base class comes from another module involved in a circular reference (because the base constructor hadn't been imported).

At the moment I'm using SystemJS and TypeScript together by using the CommonJS module output format.

Hopefully we get to see this in TS1.5 :)

[mhegazy]

@jamiewinder with the new ES6 module syntax supported by TypeScript 1.5 you can get most of your circular references issues done.

e.g.

import { two } from "./module2";

export function one(counter: number) {
    two(counter);
    console.log(`in one ${counter}.`);
}

import { one } from "./module1";

export function two(counter: number) {
    if (counter) {
        one(--counter);
    }
    console.log(`in two ${counter}.`);
}

two(3);

running

tsc --m commonjs module2.ts

and

node module2.js

results in:

in two 0.
in one 0.
in two 0.
in one 1.
in two 1.
in one 2.
in two 2.

The reason is these module aliases will be rewrite by the TypeScript compiler, so my module1.js looks like:

var module2_1 = require("./module2");
function one(counter) {
    module2_1.two(counter);
    console.log("in one " + counter + ".");
}
exports.one = one;

where all references to two is rewritten as module2_1.two.

The cases where you need systemJs support is cyclical references in the main module body (i.e. not wrapped in function and classes) and in practice these are really limited scenarios.

[jamiewinder]

I'm using the TypeScript 1.5 Alpha with the ES6 module format. This is an example from an issue I raised on the SystemJS repo (though I'm not sure it's a SystemJS issue):

mod-a.ts

import { ClassB } from './mod-b';

export class ClassA
{
  constructor()
  {
  }

  public isB(): boolean
  {
    return this instanceof ClassB;
  }
}

mod-b.ts:

import { ClassA } from './mod-a';

export class ClassB extends ClassA
{
  constructor()
  {
    super();
  }
}

index.ts

import { ClassA } from './mod-a';
import { ClassB } from './mod-b';

var a = new ClassA();
var b = new ClassB();

window.alert(a.isB());
window.alert(b.isB());

The result is an error in the TypeScript __extends function (for ClassB) where the prototype is being set to that of the base constructor function. This because the base constructor wasn't imported (was undefined).

To clarify, this is ES6 modules, using TypeScript 1.5-alpha to output them as CommonJS format modules, to then be imported with SystemJS. So it's difficult to say where the issue is!

EDIT: A reply to my issue on the SystemJS repo suggests that it's CommonJS that's responsible for this. So, again, I certainly hope we can see register support in the TS 1.5 release. 😄

[mhegazy]

I think the issue here is order of imports.. so modifying your index.ts, to:

import { ClassB } from './mod-b';
import { ClassA } from './mod-a';


var a = new ClassA();
var b = new ClassB();

console.log(a.isB());
console.log(b.isB());

node index.js

i get:

false
true