Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add index.ts file when using modules #34

Open
Crozin opened this issue Mar 15, 2017 · 7 comments
Open

Add index.ts file when using modules #34

Crozin opened this issue Mar 15, 2017 · 7 comments

Comments

@Crozin
Copy link

Crozin commented Mar 15, 2017

Automatic generation of index.ts file containing imports would be a pretty neat feature. AFAIK right now if we're using modules we need to import each file independently in TS code:

import { ContractA } from "contracts/ContractA";
import { ContractB } from "contracts/ContractB";
import { ContractC } from "contracts/ContractC";
import { ContractD } from "contracts/sub/ContractD";
import { ContractE } from "contracts/sub/ContractE";

If Reinforced.Typings would generate two index.ts files inside contracts and contracts/sub directories we would be able to improve readability:

import { ContractA, ContractB, ContractC } from "contracts";
import { ContractD, ContractE } from "contracts/sub";
@pavel-b-novikov
Copy link
Member

pavel-b-novikov commented Mar 15, 2017

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
Copy link
Author

Crozin commented Mar 16, 2017

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
Copy link
Member

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

@cyptus
Copy link

cyptus commented Nov 14, 2018

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)

@mikejf-pr
Copy link

mikejf-pr commented Feb 11, 2019

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.

@zolakt
Copy link

zolakt commented Feb 5, 2020

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
Copy link

Rudokus commented Feb 19, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants