I am looking at using typescript within node, and am currently used to using typescript via the ///<reference.../> syntax purely using internal modules. However with larger projects this can get unwieldy as you can have modules referencing other modules which all have interlinking references.
So for this node project I was thinking about trying to group all logical components as internal modules/classes much like before, so they will all internally reference each other, but expose them via one external module which would expose the underlying classes etc.
This way the syntax would be very similar of nodes existing requiring mechanisms, like:
import database = require("my-external-db-module.ts");
var connection = new database.Connection(someUrl);
rather than
///<reference path="my-internal-db-modules.ts" />
var connection = new Database.Connection(someUrl);
And I imagine the syntax would be something like:
///<reference path="all-my-internal-module-files-etc.ts" />
///<reference path="..." />
export module SomeExposingModule
{
// Not quite sure what to put in here to expose the internal modules
}
So are there any sort of best practices around this sort of thing or any others who have done something similar, or does everyone just stick to using internal modules for complex stuff?
I am not sure if this is bad practice or not but here is how I solved my problem.
First a quick summary of the problem again:
I have multiple files all logically grouped under a namespace, for example Framework then all files under there will be Framework.*, such as Framework.Database or Framework.UnitOfWork. Then these are all compiled via tsc --out framework.js ... so I get all of this outputted into a framework.js file.
Now the above sounds fine, however it does not allow you to export modules when using --out because it spans multiple files, so for node to work I need to export the modules somehow, so I basically appended an extra typescript file which manually does this for me in the compilation:
// exporter.ts
module.exports = Framework;
So providing this is the last file added to the tsc compilation you will end up with something like:
// Framework.js
var Framework;
(function (Framework) {
// lots of good stuff
})(Framework || (Framework = {}));
module.exports = Framework;
So this will export the internal modules fine and the export declaration will be included now because of the exporter.ts file which is now included.
So I am not sure if this is bad practice but this allows me to have the best of both worlds, a re-usable module which is laid out with namespaces and is spread across a sensible file structure, and a compiled single module which can be included either by references or by nodejs require.
So the usage would look like:
var Framework = require("./framework");
var database = new Framework.Database.DbConnection();
There are some ideas that help to smooth some of these issues.
If you have a lot of references, you can use a reference file to manage them. For example:
references.ts
///<reference path="a.ts" />
///<reference path="b.ts" />
///<reference path="c.ts" />
///<reference path="d.ts" />
All other files...
///<reference path="references.ts" />
You now have a central list of your references, which is much easier than weaving lists of references at the top of each file.
In your specific case, I would be more inclined to use import statements and get NodeJS to load modules for me - and I would group modules using the file system.
What you can do is that compile a set of TS files into a .js + d.ts combination. e.g. the following creates out.js and out.d.ts
tsc a.ts b.ts --out mod.js --declaration
And then (hopefully) the following will work:
///<reference path="mod.d.ts">
var mod = require('mod')