Suggestion: TypeScript Library Project in Visual Studio

[RyanCavanaugh]

Create a project template and project system support for a TypeScript 'library'

Library project outputs would include a .d.ts and a .js file; referencing projects would consume the .d.ts file automatically and have separate compilation. Refactoring in the referenced project would be reflected in any loaded referencing projects.

[jvilk]

Library project outputs would include a .d.ts and a .js file

This would be excellent as a standalone compiler feature. As it stands, my multiple AMD module projects are compiled into a single JS file using the RequireJS compiler, but there's no way to automatically tell the TypeScript compiler to do the same for their declaration files (you end up with one .d.ts per module). This is problematic for the same reason: I have no 'clean' way to reference one library from another (although I am using npm modules, not Visual Studio projects).

My use case is that one module ends up being the exported 'frontend' in a global variable, from which all library functionality is exported. If this is the common case, then perhaps TypeScript could support a command line option for emitting a .d.ts file that contains the frontend module exported as a particular global variable, and all types/modules that are 'reachable' from the frontend.

Namespacing might be an issue here when you are using 100% AMD/CommonJS modules; I haven't thought too deeply about it yet.

[andrewvarga]

This is somewhat related to #293 as that also aims to help using library projects.

Library project outputs would include a .d.ts and a .js file

To me this wouldn't be a feature I'd use, as one of the advantages for using typescript library projects (specified with a custom path) would be that I only use the classes/modules that I need, there's no point packing everything together when I may only use one small feature of it.

[MrKWatkins]

I would love to see a dedicated project type for TypeScript in Visual Studio that handles references and copying of output around automatically, in much the same way that a C# project automatically copies around it's assemblies. Currently I have the following:

• A web project containing core TypeScript code.
• A web project containing tests for the core code.
• Two different websites in different solutions that both use the core code.

To make this all work I have to:

• Have pre-build actions to copy the .js and .d.ts files from the core project into the websites and test project before building.
• Specify 'Combine JavaScript output into file'.
• Specify the two root directories to get s in the output .d.ts correct.
• Make the websites and test project reference the core project. Without this we can't guarantee that our core project is built first so we might copy an old version into the other projects

The problems with this are:

• You lose TypeScript debugging for the core project - you instead have to step through the final .js output. (Even if you copy the .js.map files across -
• It's a lot to setup! (No-one likes using pre/post build actions if they can help it...)

Minor problems:

• Because the web projects are really C# projects you get empty .dlls floating around the place.
• Any references to third party typings in the Core project come through as s in the output .d.ts file. Due to their paths this forces me to put them in my root directory, rather than Scripts\typings.

Now it maybe that I'm not setting these projects up correctly and some of these things can be fixed. (s seems like it should be fixable for instance) But in an ideal world there would be a dedicate project type for TypeScript that solves all this automagically for me. The project would:

• Contain just TypeScript only. No empty C# .dlls. If I want webpages/C# as well, as I might for unit tests, then I can just use the existing web project.
• Be referenceable by other TypeScript projects and web projects.
• Automatically copy the .js output into the target project on build, much like a C# .dll is automatically copied around. Maybe allow the path for it to be specified in target web projects? (E.g. a web project by default puts its .js files under /Script but you might want that to be configurable)
• The biggie - when debugging a web project that references a TypeScript project I'm able to put breakpoints in the .ts files in the TypeScript project and have them hit. (Instead of the having to hit breakpoints in the output .js file in the web project.)
• Also automatically copy .d.ts/.js.map if needed to make everything work, changing references directories in them as necessary. (This is really an implementation detail for me - I don't care if there files are there or not provided the above works!)

That's how I see it working anyways, hope it helps. Happy to give more detail and help out if you want, get in touch.

[joewood]

Wouldn't the simplest solution be for Visual Studio to support the new .tsconfig file? A simple TypeScript only project that uses this new file to drive the settings for the compiler. Debugging would be supported using source maps.

I'm not sure we need a new way to do package sharing/references over and above the normal web way of using npm and browserify etc...

[MrKWatkins]

You say 'normal web way'... But that's not what I'd consider normal...

So from my point of view, this is what's happened.

• I've been doing ASP.NET and ASP.NET MVC for websites for years.
• Need to start a new website, so I fire up Visual Studio and create a website project.
• I think "right, TypeScript sounds good, I'll code in that instead of JavaScript for all the client side code that is gonna run in my users' browsers".
• I then need to start another website, so I fire up Visual Studio, create another website project and use TypeScript in it.
• Then I decide "right, I'm writing the same code in both websites, lets see if I can share it". So I go to add a new project in Visual Studio, see the TypeScript project, add that in and go from there.

That's normal from my point of view. :)

Now if I'm supposed to be using Node and NPM and Browersify and so on, that's fine. Happy to go with the norm. Where is that documented though? I can't see anything on typescriptlang.org or the Visual Studio docs about setting up TypeScript projects in VS and using NPM and the like. I've done a lot of web searching about TypeScript projects without much luck.

Also if its the norm then why doesn't the website/TypeScript projects in Visual Studio use all that stuff already? Maybe that's the answer - change those projects (or create new ones) that use this NPM/Browserify approach.

Also with NPM - would I also then be in a position where I have to use NPM as my package manager for JavaScript stuff and NuGet for the rest? That would suck!

Sorry if that sounds like I'm moaning, I'm really not. Just as a relative newbie to TypeScript setting all this stuff up has proved hard for me so if we could make it easier for other newbies that would be great. And if one of you could tell me the answer to my problems then that would be even better still. :P

[NoelAbrahams]

@MrKWatkins, as far as I know there is no way to mix ASP.Net/Nuget and npm.

If you want to use npm in Visual Studio then I suggest trying out NTVS. They have a lovely set of tools (interactive Node.js window, test harness, debugging) that integrate well with Visual Studio. They also have an npm UI:

I was hoping for something similar for TypeScript. @paulvanbrenk seemed to suggest that the TypeScript team is working with the NTVS team. Haven't seen anything yet.

[MrKWatkins]

Thanks @NoelAbrahams. I don't really want to use NPM to be honest, I'd just be prepared to if it solved my problems. Or if it was the accepted way of doing things. I'd really much prefer a TypeScript project as a first class citizen, with all my references and debugging automagically working.

[NoelAbrahams]

Perhaps the following two issues should be subsumed under here:

• Provide an Add Reference feature for Visual Studio projects Provide an Add Reference feature for Visual Studio projects #2180
• Provide a "Build Order" property for TypeScript files in Visual Studio Provide a "Build Order" property for TypeScript files in Visual Studio #2181

[EvAlex]

👍 Came here to suggest this feature. Found this issue already created.

[SilentPenguin]

@MrKWatkins, Another similar approach, debugging with mappings works for the setup I have.

Currently, I'm working with website projects as you discussed, and inserting links to typescript files I wish to access in my main site, this can be done just fine using the project explorer, using "Insert Existing Item" and then choosing "Add As Link". Your .csproj file then looks something like:

<ItemGroup>
    <TypeScriptCompile Include="..\..\Test.ts\Test.ts\Assert.ts">
      <Link>Scripts\Assert.ts</Link>
    </TypeScriptCompile>
    ...
</ItemGroup>

At the bottom of my project file is I've then included some post build actions to copy across the linked, and generated files:

<Target Name="CopyLinkedContentFiles" AfterTargets="Build">
    <Copy Condition="'%(TypeScriptCompile.Link)' != ''" SourceFiles="%(TypeScriptCompile.Identity)" DestinationFiles="%(TypeScriptCompile.Link)" SkipUnchangedFiles="true" OverwriteReadOnlyFiles="true"/>
    <Copy Condition="'%(TypeScriptCompile.Link)' != ''" SourceFiles="@(TypeScriptCompile -> '%(RootDir)%(Directory)%(Filename).js')" DestinationFolder="$([System.IO.Path]::GetDirectoryName(%(TypeScriptCompile.Link)))" SkipUnchangedFiles="true" OverwriteReadOnlyFiles="true" />
    <Copy Condition="'%(TypeScriptCompile.Link)' != ''" SourceFiles="@(TypeScriptCompile -> '%(RootDir)%(Directory)%(Filename).js.map')" DestinationFolder="$([System.IO.Path]::GetDirectoryName(%(TypeScriptCompile.Link)))" SkipUnchangedFiles="true" OverwriteReadOnlyFiles="true" />
</Target>

This then pulls down the typescript, and their counterpart javascript and map files to the linked location. This will only work for the default build behaviour though, without combining, and without code redirecting. Linking with recursion should be possible, not that I've tested it.

I don't know if would be possible to do, but it would be fantastic if referencing an assembly from within a project would trigger some msbuild magic to inspect the project file of the referenced assembly, instead of manually linking directly.

[r4nyc]

If you're taking this idea all the way allow a symbol package with the .ts files and one giant js..map to map the minified combined js back to the ts files.+
That way you could distribute a package developed in typescript and allow developers to step into the source just like you can with .net assemblies.