Combine JavaScript Output into File Doesn't Appear to Work

Topics: General
May 18, 2014 at 1:15 PM
Hello Community,

I've created a new TypeScript HTML Application in Visual Studio 2013. I configure this project to be CommonJS, and to "Combine JavaScript output into file" in the Project Settings.

I add a new TypeScript File to the project, which creates the IPoint interface (which seems to conflict/contradict the guidance provided with interface naming in the TypeScript documentation) and the Shapes module and Point class.

If I place an export in front of the interface/module like so:
export interface IPoint {
    getDist(): number;
}

// Module
export 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);
    }

}
And then compile my project, the code does not get output into the single file that I configured in Project Properties. Instead, it gets output into a separate file which is not what I configured.

Is this a known issue/bug? Any guidance/explanation would be greatly appreciated.

Thank you,
Michael
May 18, 2014 at 3:33 PM
One may not combine external modules into a single output file.

That doesn't make sense because external modules are meant to be loaded each individual file at a time.

See the last section "Trade-offs for External Modules" in the official docs.
Marked as answer by MichaelDBang on 5/18/2014 at 7:50 AM
May 18, 2014 at 4:02 PM
Edited May 18, 2014 at 4:03 PM
Thanks again for your assistance, nabog. I will read that document thoroughly. I guess what I was looking for was a "packaging" mechanism for TypeScript projects, something like what requirejs uses, but it looks like that (requirejs packaging) is exactly what I would have to use to get what I am aiming for here.

I suppose a motivating factor here is that I absolutely despise having to use a string to identify my modules. This seems like an obvious contradistinction to static-type checking and type safety that TypeScript is supposed to provide. That is:

var instance = new NameSpace.Type();

... seems so much more natural, intuitive, and congruent than having to do:

import NameSpace = require( "NameSpace" );
var instance = new NameSpace.Type();

Aesthetics aside, I have to use two lines of code for something I should be able to do in one.

It just seems like there should be some compiler sugar that can be applied here to make this work more like a static type-based IDE. I might be missing something obvious here, so if that is the case, please feel free to enlighten me.
May 18, 2014 at 7:35 PM
MichaelDBang wrote:
I absolutely despise having to use a string to identify my modules. This seems like an obvious contradistinction to static-type checking and type safety that TypeScript is supposed to provide.
It just seems like there should be some compiler sugar that can be applied here to make this work more like a static type-based IDE.


@MichaelDBang, this is a natural way of thinking when first encountering TypeScript, i.e. why doesn't TypeScript correct certain obvious problems with JavaScript, or do other things a bit more elegantly?

There are two reasons for this
  • TypeScript attempts to be minimally intrusive when it comes to converting the actual code that is composed by the developer into the corresponding JavaScript.
  • TypeScript attempts to align itself with upcoming iterations of the EcmaScript standard for JavaScript.
That may explain why certain constructs in the language are the way it is.

Regarding the static type checking, that isn't really an issue here, because TypeScript checks the string path for the require and produces a compile time error. See overload on constants for another case where strings are checked at compile time.
May 18, 2014 at 8:47 PM
I understand that strings are checked at compile time, but that doesn't make it any less uglier. :P Everyone might be used to typing "createElement( 'canvas' )" ... but under the covers, there is a "new Some.Namespace.Canvas()" expression being executed somewhere in the host browser's DOM API.

I am just saying that JavaScript has an opportunity to grow up here, and TypeScript is the catalyst that should enable exactly that. I say this as a developer with over a decade of experience in C#/.Net, who is frustrated of not being able to run client code ubiquitously (MSFT still hasn't "got it" since Siverlight/Mix'11), and is inspired by what TypeScript is capable of doing in future versions.
May 18, 2014 at 10:35 PM
After reading that wiki page, I am a bit confused around the "Needless Namespacing" section. It seems as if the article is suggesting to not use
export Module ModuleName {}
... at all. If that is the case, why provide the capability to do this in the first place?
Developer
May 19, 2014 at 7:38 PM
There are many situations you might want to export a module. The guidance there is simply to not use an exported module if its only purpose is to wrap the entire contents of the file in a name, as the filename already does that for you. For example, you may want to write this:
module M {
    export module N {
        export var y = 1;
    }
}

var x = M.N.y;
or
export class C {
    foo() { }
}

export module C {
    export var aStatic = 1;
}

// create a 'clodule' C that is both a class and a module, and export it along with an instance of that type
export var c = new C(); 
May 20, 2014 at 1:59 AM
Hmmm... alright. This is obviously going to take some getting used to. It would be great if there were some sample solutions out there that highlighted some of this functionality. In any case, I appreciate the assistance!
May 20, 2014 at 10:46 AM
Unfortunately, JavaScript growing up is something that requires the engagement and agreement of the entire TC39 committee, and the last catalyst that was powerful enough to enable something that unlikely was the Big Bang.

May 20, 2014 at 1:46 PM
but, TypeScript isn't ruled by committee is it? When I say "grow up," I am talking about the compiler sugar and tooling that TypeScript can provide around JavaScript to make it behave more like a type-safe language (C#, Java) while still being conformant to any prevailing standards (and yes, even committees) out there.