greymind / webapitotypescript

A tool for code generating TypeScript endpoints for your ASP.NET Web API controllers

Web API To TypeScript

A tool for code generating TypeScript endpoints for your ASP.NET Web API controllers and their actions. No more need for dumb repositories!

• Generates typed endpoints with required and optional parameters for GET, PUT, POST and DELETE verbs
  • Generates cached endpoints for GET verb actions
• Generates enumerations and interfaces for DTOs used in all controller actions
  • Generates enum descriptions based on the [Description] attribute
• Generates Angular service to expose typed call() function to fetch response from server
• Generates typed views to use on front-end
• Generates resources files based on .resx files

Examples

Take a look at the generated files and sample test files here

Getting the tool from NuGet

https://www.nuget.org/packages/WebApiToTypeScript/

Install-Package WebApiToTypeScript

Using as standalone tool

Just run the executable with the config file as the argument

watts.exe "Path/To/Config/File.json"

Using as MSBuild Target

I haven't tested this in a while, so if you find any inconsistencies with working directory and such, feel free to file an issue or better yet, submit a pull request!

Ensure the DLL is part of the build process, so you have access to it. Easiest way is to reference it in your project.

<UsingTask TaskName="WebApiToTypeScript.WebApiToTypeScript" AssemblyFile="$(ProjectDir)..\WebApiToTypeScript\bin\Debug\WebApiToTypeScript.dll" />
<Target Name="AfterBuild">
    <WebApiToTypeScript ConfigFilePath="$(ProjectDir)Watts.config.json" />
</Target>

T4 Template

If you wish to integrate the executable as part of your workflow from within Visual Studio, you may consider wiring it up to a T4 template. Here is a sample.

Protip

You can build just the C# parts of the solution by adding a condition to the TypeScript target in the csproj file. This way you can ensure that before you run WebApiToTypeScript, you have a hassle-free build of the backend code.

  <PropertyGroup>
    <SkipTypeScript Condition="'$(SkipTypeScript)'==''">False</SkipTypeScript>
  </PropertyGroup>
  <Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets" Condition="Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets') AND '$(SkipTypeScript)'=='False'" />

Path\To\msbuild.exe /t:build /p:SkipTypeScript=True Path\To\Project.csproj

Using Angular Endpoints Service

You'll need to register the Endpoints service to your app and inject it as is typical in Angular

angular.module('framework').service('AngularEndpointsService', Framework.Endpoints.AngularEndpointsService);

Config

{
  "WebApiModuleFileName": "string",
  "WebApiModuleFileNames": [ "string" ]
  
  "GenerateEndpointsReturnTypes": "boolean",
  "GenerateEndpoints": "boolean",  
  "EndpointsOutputDirectory": "string",
  "EndpointsSupportCaching": "boolean",
  "EndpointsFileName": "string",
  "EndpointsNamespace": "string",
  
  "GenerateMobileEndpoints": "boolean",
  "MobileEndpointsOutputDirectory": "string",
  "MobileEndpointsFileName": "string",
  "MobileEndpointsNamespace": "string",
  "MobileEndpointAttributeName": "string",

  "GenerateService": "boolean",
  "ServiceOutputDirectory": "string",
  "ServiceFileName": "string",
  "ServiceNamespace": "string",
  "ServicesName": "string",

  "GenerateEnums": "boolean",
  "GenerateEnumDescriptions": "boolean",
  "EnumsOutputDirectory": "string",
  "EnumsFileName": "string",
  "EnumsNamespace": "string",

  "GenerateInterfaces": "boolean",
  "InterfacesOutputDirectory": "string",
  "InterfacesFileName": "string",
  "InterfacesNamespace": "string",
  "InterfaceMembersInCamelCase": "boolean",
  "InterfaceCamelCaseCustomAttribute": "string",
  "InterfaceMatches": [
    "Match": "string",
    "ExcludeMatch": "string",
    "BaseTypeName": "string"
  ],

  "GenerateViews": "boolean",
  "ViewConfigs": [
    {
      "SourceDirectory": "string",
      "Namespace": "string",
      "OutputFilename": "string",
      "Prefix": "string",
      "UrlEncodePath": "boolean"
    }
  ],
  "ViewsPattern": "string",
  "ViewsOutputDirectory": "string",
  "UseViewsGroupingNamespace": "boolean",
  "ViewsIgnoredExtensions": [
      "string"
  ]

  "ScanOtherModules": "boolean",
  "WriteNamespaceAsModule": "boolean",

  "TypeMappings": [
    {
      "WebApiTypeName": "string",
      "TypeScriptTypeName": "string",
      "AutoInitialize": "boolean",
      "TreatAsAttribute": "boolean"
      "TreatAsConstraint": "boolean",
      "Match": "string"
    }
  ]
}

License

MIT

webapitotypescript's Issues

Add support for more enum functionality

We have a tool that generates enums and one enum looks like this:

AccountType: {
  "Basic": {
    "Value": 1,
    "ValueName": "Basic",
    "Title": "Basic"
  },

This gives us more flexibility if we need to generate some text from enum or similar.
It would be nice if this tool provided a way to fetch similar data.

EnumMatches configuration is ignored

It seems that all enums are always exported regardless of EnumMatches configuration.

Generate JSON Schema For Config

Figure out best mechanism to support return data types

It is a fairly challenging problem to figure out the best scheme to detect and support return types for controller actions. Many different control flows could exist, and often times the signature of actions just reads IHttpActionResult!

Support prefixes for view paths

Add support to handle generic instances

Simple things such as ClassWrapper, etc.

Watts.exe fails when base type is a generic one

Watts.exe fails when a base type is a generic one.

We have multiple base types with single generic argument and watts is working fine, however it fails with a generic base type that has 3 generic arguments (not sure about 2, did not check that out).

It fails inside InterfaceService in WriteInterfaces(TypeScriptBlock interfacesBlock, InterfaceNode interfaceNode) method on the foreach line. The exception we get is that the collection was modified.

Looking forward to this fix, because we had to utilize interfaces to go around this and that introduced some code duplication.

Thanks!

Separate non-backend related tools in to a separate project

Project has a few features that do not really fit into the backend-to-frontend WebApi to TypeScript pipeline. Such as views and resource file generation. Discuss and if deemed right, move those features to new project(s).

Write exhaustive test application

Test application needs improvement to demonstrate all the features. Needs multiple angular directives and apps for starters.

Make watts generated view path as lower case

Add support for before and after handlers in Angular Endpoints Service

Watts generates views for .orig files

Watts not picking up base type in certain cases

Best guess is different assembly with mono cecil

For resources with multiple usages of same parameter, duplicate identifier problem occurs.

eg:

<data name="EntityAddToLibrary" xml:space="preserve">
    <value>The {0} has been added to the {0} library.</value>
</data>

gets generated as:

static EntityAddToLibrary(slot0: string, slot0: string) {
            return \`The ${slot0} has been added to the ${slot0} library\`;
}

Move support of collection types into TypeService.GetTypeScriptType

Clean up type handling, especially generics

• A few duplicated type handling instances should be consolidated and grouped
• Generics are not handled all the way through, only a couple of levels, if that

Generated TypeScript definitions sometimes get reordered on different build machines

Output of the typescript generator is not completely deterministic. It appears that, on different machines, it sometimes generates definitions in different order. This causes spurious file modifications and merge conflicts if generated files are kept in source control.

It is not clear in what exact circumstances this happens.

Add support for Angular 4 in angular endpoints service

Generate endpoints service using angular 4 techniques and methods.

Allow camelcase export per controller

Some of my controllers return camel case properties and others return pascal case. I need a way to handle it :)

Thank you @greymind <3

Add support for caching last request.

Add support for .callCached() method in AngularEndpointsService.

If the same method was called before, this method would grab whatever was received last time.
In case this method is being called first time, it should automatically fetch data from .call() version.

Add support for throttling/debouncing

Investigate moving to some other readable templating mechanism

Now that the code logic is complete, investigate if we can move to Razor or T4 and make it more readable, elegant and maintainable!

Use multiple threads for interface scan

Investigate and implement a solution which uses multiple threads for interface scanning. Perhaps extend to other scans as well.

Add support for custom headers in call()

Handle JsonPropertyAttribute

For now, at least PropertyName

Ignore properties marked with JsonIgnore attribute

Implement simple action return types.

AngularEndpointsService calls sometimes do not trigger a scope digest

Issue due to leftover artifact static $http in the service.
Crazy how this wasn't diagnosed all this while!

Improve performance of code when compiling for ES5

Add support for scanning multiple DLLs

Currently watts supports scanning of only one DLL for controllers.

Our use case requires scanning of multiple DLLs.

Could you please add the support for this requirement :)

Code clean up

Clean up code. Please use this thread to identify overall points of cleanup or spawn off into a new issue if it is focused and actionable.

Handle collisions in enums by growing the name prefix with namespace parts

Currently, two enums with same name, but under different namespaces collide and we generate a warning. Instead, we can "grow" the name by prefixing the minimum namespace parts required to make it identical.

For example:

namespace Something.Else.Here {
    enum EnumType {
    }
}

namespace Something.There.Here {
    enum EnumType {
    }
}

The generated names can be

ElseHereEnumType
ThereHereEnumType

Perhaps do this for other types as well