Add support for file include.

[Izhaki]

It seems that one of the likeable features of TypeScript, compared to Babel lets say, is that it emits readable code.

Consider the following code:

X.ts:

namespace a.b.x {
    class X {

    }
}

Y.ts:

namespace a.b.y {
    class y {

    }
}

This emits:

var a;
(function (a) {
    var b;
    (function (b) {
        var x;
        (function (x) {
            var X = (function () {
                function X() {
                }
                return X;
            })();
        })(x = b.x || (b.x = {}));
    })(b = a.b || (a.b = {}));
})(a || (a = {}));

var a;
(function (a) {
    var b;
    (function (b) {
        var y;
        (function (y_1) {
            var y = (function () {
                function y() {
                }
                return y;
            })();
        })(y = b.y || (b.y = {}));
    })(b = a.b || (a.b = {}));
})(a || (a = {}));

There's a lot of code redundancy, which can really clutter the emitted output for projects that rely heavily on namespaces.

Wouldn't it be nice if we could just do something like this:

namespace a.b {
    export namespace x {
        /// include X.ts
    }
    export namespace y {
        /// include Y.ts
    }
}

The include statement simply places the included file into the script during pre-compilation.

My guess is that this is already partly implemented with /// reference, only that ///reference doesn't seem to work unless it's either the first line, or one succeeding another /// reference.

[mhegazy]

there are scoping issues at play here that would make tooling for this fairly hard. it also makes external and internal module syntax ambiguous.

The original issue is tracked by #447.

[Izhaki]

@mhegazy, I don't really see how this issue is a duplicate of #447. #447 is about compiler optimisation and I agree with everything you say in your comment here about it.

But we are talking here of a simple include, so any scoping issues are the developer problems and not that of the compiler.

I mean, you get the same feature in C++, and one could easily do this with libraries like grunt-include-source.

Something like this could also help with the redeclaration overhead of the current mixins guide.

[mhegazy]

C++ template, processor directives, includes are all nice features, but they make tooling very hard and adds significant complexity to the language. I do not think we would be open to supporting such features.

As for this proposal here are some of the issues we would run into:

• to identify whether a namespace is exposed on its parent, it needs to be exported. so in the example above, you need to have x.ts look like export namespace x {..}. this is ambiguous from the get go, as now we do not know if this is an external module or just a nested namespace. if not then this changes the errors you get in a file based on how another file includes it, which is inconsistent at best.
• single file compilation is completely busted, as in isolation, we have no way how to emit this file
• opening a file in your IDE does not tell the IDE what is the lexical scope. a lot of the implementation of lexical scope features in LS today (e.g. navigationbar items) depend on knowing the lexical context of a module.
• using comments to change scoping is just not right. We already have /// references and do not think we need to add more.

I think the issue is the shape of the emit. if you agree, this should be an emitter change, that "optimizes" the output by compiling namespace declarations if you use --out. which i believe is covered by #447.