Feb 12, 2013 at 8:12 AM
Edited Feb 20, 2013 at 1:25 AM
We in the process of adopting TypeScript in our HTML5 high-end games platform (see
to try some of the games). In general it's all going very well, but there are a few little problems I've had with the behavior of the compiler.
conceptual 'modules' (which can depend on other modules), each of which produces a .js and .d.ts file.
If we use '/// <reference ...' to refer to the types in other .ts files then the resulting .js and .d.ts each contain all the code and declarations for dependent modules. When an app then uses multiple modules from our engine we get a lot of errors because
types are declared multiple times. To work around this, we don't use the '/// <references', but use the dependencies between modules specified in our build scripts to build the .js and .d.ts for dependent modules, and then pass those to the compiler on
the command line.
This works fine, but since there are no '/// <reference ...' statements in the code, the Visual Studio plugin is unable to resolve types in other files, even in the same project. On the one hand, the VS plugin forces us to use references to other .ts files
(I can't find a way to set up a project that doesn't require this), but adding references pushes all dependent code and decls into the output from each module.
We are currently working around this by including references to keep VS happy, and using the --noresolve flag when building our library. We then have a second 'checking' build which builds each file individually (without --noresolve), thereby ensuring that
the references are maintained for the people using VS.
Before I start submitting feature requests I'm interested to know if I've overlooked something and should be doing the build in a different way. Or maybe this is just something that hasn't been addressed in the compiler yet.
Thanks in advance for any suggestions.