This project is read-only.

External Modules really require one giant code file?

Topics: General
Apr 3, 2014 at 10:42 PM
So I have a collection of algorithms that I want to turn into a library. The consumer of this library is going to be a node.js-based application. I want to do the algorithms in TypeScript for the usual reasons. Of course, I need the JavaScript output by this TypeScript to be able to be imported into node.js. To help test this, I'm using mocha in a separate node.js test app.

So I've run into a couple of problems, but at this point I have only one major issue left: It seems that in order to allow for the node.js consumer to import my code as a single module, that all of my code has to be in a single file.

Is this correct? It feels as though I must be missing something as that's obviously not sustainable for even a medium-sized project. Or is my use case considered an edge case?

Again, I want the consumer of my code to be able to do something like:
var algorithm = require('algorithm.js')
And access all the namespaces/classes within algorithm.

Thanks in advance.
Apr 6, 2014 at 11:42 PM
No, node js applications do not require one huge file, quite the opposite. Node is all about small commonjs modules.

TypeScript supports this with the external modules (see handbook etc).

You'd write you application (or library) as external modules (eg: export's and imports'). There will be one main file (usually index.ts) that exports the API your users would use. This module imports the parts of your application needed to do that, and those all have their own import/exports and so on. Anything that is not exported from your main file is not visible to users (this is quite the opposite from the internal modules, that are one big namespace pile and indeed need one huge file).

You start the compiler on just main file, and use an output directory and the commonjs module format. This creates JS version of all used TS modules.

Later you publish the JS to npm, and in the package.json you set the main property to point to the JS version of your main file.
Marked as answer by ApollyonBoB on 4/14/2014 at 11:42 AM
Apr 14, 2014 at 8:09 PM
It took forever for me to get this working for an issue I just discovered is unrelated. The sooner they can get tools for node.js unit testing that actually work within Visual Studio's IDE the better. Can't get any of them working with NTVS and it's super annoying.

But like I said, unrelated to this issue.

Importantly, it seems as though this does not work with internal modules, and you have to include all of the referenced files with it.

For instance, if you have an index.ts file that references an internal module, attempting to compile on just the main file results in an error. I mean, as one might expect. Compiling all of them into a single external file does get you that internal module -- but putting something like
export var externalName = InternalModule;
Doesn't actually work. It doesn't show up anywhere in the output file. So there's no way to "export the API" as you put it. I've tried all sorts of variation, but this seems closest to the one that should work, and just doesn't. I put a reference to the InternalModule in the index.ts. Here's the weird part - if I comment out everything in index.ts, the comments show up after the InternalModule in the output file. If I uncomment the export var, blam, it's gone. So that's weird.

I kind of got it working though with several large external modules that are referenced by a single other module. Not exactly what you described, but close enough I marked it as the answer.
Apr 14, 2014 at 8:15 PM
As a side note, I did get it to compile on the main file and the _references file. That seemed to work. However, I ended up with the exact same results. Putting export var causes the contents of index.ts to not show up.