Add index.ts file when using modules about reinforced.typings

[cyptus]

i managed this by generating the models into single files per namespace:

[assembly: TsGlobal(
    GenerateDocumentation = true,
    UseModules = true,
    DiscardNamespacesWhenUsingModules = true)]
namespace xxx.Shared.DTO
{
    public class TypingsGeneratorConfiguration
    {
        public static void Configure(ConfigurationBuilder builder)
        {
            var dtoInterface = typeof(IDataTransferObject);
            var dtoTypes = AppDomain.CurrentDomain.GetAssemblies()
                .SelectMany(x => x.GetTypes())
                .Where(x => dtoInterface.IsAssignableFrom(x))
                .Except(new Type[] { typeof(IDataTransferObject) });

            builder.ExportAsClasses(dtoTypes, x => x.WithPublicProperties().ExportTo(NamespaceToFilename(x.Type.Namespace)));
        }

        public static string NamespaceToFilename(string namespaceName)
        {
            return String.Join("/", namespaceName.Replace("xxx.Shared.", "").Split('.')) + ".ts";
        }
    }
}

(i replace the namespace prefix to shorten the path to the models)

[zolakt]

I'm throwing in my vote for this feature as well.
For anyone interested, here is the workaround I have currently, with a custom TsCodeGeneratorBase.

Basically, you generate each class 2 times: once with a "normal" generator, and once with this "IndexTsGenerator"

public class IndexTsGenerator : TsCodeGeneratorBase<Type, RtRaw>
{  
    public override RtRaw GenerateNode(Type element, RtRaw node, TypeResolver resolver)
    {
        return new RtRaw($"export * from './{element.Name}'");
    }
}

And when you call the generator, you do something like this:

...

classBuilder
    .WithAllProperties()
    .ExportTo(filePath);

classBuilder
    .ExportTo("index.ts")
    .WithCodeGenerator<IndexTsGenerator>();

...

[Rudokus]

@zolakt I am trying to use your workaround. But it seems it will only generate once with ExportAS.. method.

[pavel-b-novikov]

import { ContractA, ContractB, ContractC } from "contracts";

How much Contracts you would like to have?

Also RT intentionally reveals each import to separate line to avoid long import at the beginning of file. IMHO it does not improve readability, doesnt it?

[Crozin]

Right now I'm working on a project with few dozen of C# contract classes (input/output DTOs for WebAPI) divided into serveral namespaces. I'm using GlobalConfigurationBuilder.UseModules() therefore RT generates a separate TS file for each class/type inside hierarchical directory structure. For those files single import per type is absolutely fine. At the end of the day readability of autogenerated sources is not important.

What I was writing about was actual source code of my TS/Angular application where I have to write something like:

import { Component, OnInit }    from "@angular/core";
import { Subscription }         from "rxjs/Subscription";

import { Listing } from "../../../contracts/Listing";
import { Selector } from "../../../contracts/Selector";
import { JobCastSnippetListingEntry } from "../../../contracts/Projections/JobCastSnippetListingEntry";
import { CategoryNode } from "../../../contracts/Projections/CategoryNode";
import { JobCastListingFilters } from "../../../contracts/Filters/JobCastListingFilters";

Instead of little bit more compact:

import { Component, OnInit }    from "@angular/core";
import { Subscription }         from "rxjs/Subscription";

import { Listing, Selector } from "../../../contracts";
import { JobCastSnippetListingEntry, CategoryNode } from "../../../contracts/Projections";
import { JobCastListingFilters } from "../../../contracts/Filters";

---

Take a look at... let's say angular/http: https://github.com/angular/angular/tree/master/packages/http/src - several TS files and one index.ts with exports.

[pavel-b-novikov]

Ah, got it.. Well.. It might be not so difficult to do that, but I totally do not have free time.

[mikejf-pr]

I'd like to throw my voice behind this request: we prefer to split out the classes into separate files for convenience and avoiding git merge hell in large many-person projects, but it does cause the irritations that Crozin has raised.