project references + build targets

Topics: General, Language Specification
Jul 5, 2013 at 4:30 AM
Edited Jul 5, 2013 at 4:31 AM
I am working on a javascript project using Typescript professionally, and here are my biggest "wants". Could someone please let me know if these features are planned, or if there are any work-arounds? I use the VS plugin, but this can probably also be applied to tsc.exe too

1) Project References
I would like to put shared utilities into a seperate typescript project, and reference those from another project. I can't do this today because references below the project root would break pathing when running in a webserver, and copying the library files is a weak compromise because then i have duplicate code files sprinkled around and managing this manually is complex/annoying.

2) build targets
i have a set of libraries that I wish to use in Node and browser. unfortunatly our node team is using CommonJS while we are using AMD for the browser. right now I can't build for both (building one overwrites the other)
Jul 5, 2013 at 7:49 AM
If you are using visual studio, can you not branch the files from one project into a folder in the other project?
Jul 5, 2013 at 8:11 AM
@Griffork, sorry I don't know what you mean by "branch the files".

If you mean checkout the file from a revision control system in multiple locations, that's a logistical problem and technically complex. (fyi, I use mercural)

If you mean something else, please elaborate.
Jul 8, 2013 at 2:32 AM
Ahh, if you're not using TFS then it probably isn't an easy answer for you.
Essentially it's like checking out another solution inside a solution, but visual studio handles the complexity for you. The only problem is updating is manual, so you have to remember to do it yourself.
Jul 8, 2013 at 7:54 AM
@novaleaf

We currently have two typescript application that use a shared library. The shared library is in its own repository (git) and has its own .csproj (based on "HTML Application with Typescript"). We include the shared library as a submodule in the application repositories, and include the .csproj in the application solutions.

For the build we use /// <reference path="../Library/Reference.d.ts"/> which ref's all ts files in the library. We have set both the applications to build to a single .js (put <TypeScriptOutFile>Application.js</TypeScriptOutFile> in the application csproj). The library code is compiled into the application.js along with the application code.

The shared library don't need to have any build output for itself (though you could have it output a unit test application for example). We actually accomplish this by having an empty typescript file at the project root and in all other files set "Build Action = Content".

So we rely heavily in /// <reference> and on the fact that we compile to single js-file. But this allows us to have a single class per file without worrying about run-time latency for loading scripts.

A small warning though: we are currently experiencing HUGE performance issues with the typescript compiler/VS plugin. I don't think it has to do with our setup, but I don't really know.
Jul 9, 2013 at 1:01 AM
@MarkusJohnsson: the 0.9.x typescript plugins have a lot worse performance than before. I personally am using 0.9.0.1 and it's perf is usable (barely) but you may try going back to 0.8.3.1 if you don't need generics.

thanks for the info. I really don't like using nested-repositories because you have to remember to do a complex commit-pull dance when making any change to the sublibraries.

I toyed with a post-build script, but that adds lots of infrastructure overhead, and I work on a team that uses other ide/os's so that's not a very happy solution.

what i've settled with for the time being is to put all my projects in a root folder, and reference the sub-folders as needed.

example:
  • root/
  • root/projA.csproj
  • root/library.csproj
  • root/projA/*.ts
  • root/library/*.ts
thus when running a website the root folder is the base folder of the website, so my projects can reference the library ok.
Jul 9, 2013 at 7:35 AM
Yeah, we used 0.8.3 before and the perf was a lot better. I just reversed our linqjs.d.ts to non-generic and I think it made the perf of 0.9 better too.

My build description works equally well when you have all the code in one repo, of course. I just threw that info in to give you a complete picture.

We also had a post-build-script before. We also tried using aspx to bundle dependencies at runtime. But we settled for having typescript compile to one big JS-file. It should be said that this is for a low traffic client application. For a high traffic consumer site you probably have other priorities.