This project is read-only.

Big project structure

Topics: General
Sep 23, 2013 at 10:52 AM
I'm coming from AS3/Java and I'm used to the (Great) packages structure of my projects, and going deeper into TypeScript I've encountered the problem of "How do I structure my projects in TypeScript?"

How would you structure your big projects? when I say "big", I mean many classes.

The current solution is modules, and nesting the modules...

Two things to consider:
  1. I want to be able to load parts of my app (Not one big file)
  2. I don't want to put all my classes into huge modules, I want them separated/organized (Like packages)
Any solution out there?
Nov 17, 2013 at 8:11 PM
Hello Gil,

I do not have an answer for you, but I am seeking the same kind of advice. I am converting a very large Silverlight e-commerce product to HTML5/CSS3 with AngularJS, Bootstrap, and jQuery that is comprised of many separately loadable modules based upon user choices.

Have you discovered any good ideas about how to tackle this with Typescript?

Unfortunately, it does not look like there are many users here...


Nov 18, 2013 at 8:48 AM
Nop, still struggling with that...
The problem is that it's based on Modules, and not packages...

You can use AMD to load your modules, but new problems with raise, like the file name does not match the class name (As we're used to on packages), or that you can't separate the module into several files and still inherit classes.

Let me know if anything comes up.

Gil Amran
Nov 18, 2013 at 11:16 PM
I've done it several different ways, and I'm not happy with any of them. On my first project, I used AMD to load my modules dynamically at dev time, and then used "r.js" to merge everything together for rollout to production. But it was brittle and clunky as hell, introduced a dependency on nodejs to my build process, and took forever to get working right. And for some reason that I can't entirely recall, I needed to maintain three different versions of my load js files: one for loading in dev, one for running unit tests, and one for optimizing via r.js.

I'm not much happier with the way that I'm doing it now, but it's maybe a little cleaner in some ways. I'm doing all my compiling via tsc.exe (though I'm still editing everything in Visual Studio), I manually maintain my .cmd build files, and I've abandoned AMD modules entirely. I miss the tight Visual Studio integration, but it's a lot simpler to maintain.

I've read in other posts that the team is planning to resolve this sort of thing in the future, perhaps by means of something like a TypeScript project that can get included in web projects via something like an assembly reference.

All that said, the bad news is that there certainly doesn't seem to be any one great way to do it now. The good news is that there's half a dozen not-quite-100% crappy ways to do it.
Nov 19, 2013 at 12:16 AM

Thanks, I am not surprised by your response.

I have read scores of blogs and articles, downloaded/looked at 10-15 project examples, viewed many videos, and the only conclusion I have reached is that everyone seems to be doing their own thing using a very wide variety of tools and ad hoc processes. Maybe that's to be expected considering the infancy of the technologies.