Output isn't sorted, making merges harder/error prone

Issue #82 resolved
Paul O'Neill
created an issue

Noticed of late that TypeLite doesn't order its output in a stable way, which means that when merging code Visual Studio can end up thinking things have changes in the generated .d.ts that really have just been re-arranged. This is especially problematic if you make changes that affect the .d.ts in two branches at once then try to merge them.

Think the solution is to just have a fairly rigid ordering of output:
By namespace
Then by class name
* Then by property name

Example output at the minute:

declare module TypeLite.Tests.TestModels.Namespace2 {
interface DifferentNamespaces_Class1 {
  Property2: string;
  Property1: string;
}
interface DifferentNamespaces_Class2 {
}
}
declare module TypeLite.Tests.TestModels.Namespace1 {
interface DifferentNamespaces_Class3 {
}
}

Expected output

declare module TypeLite.Tests.TestModels.Namespace1 {
interface DifferentNamespaces_Class3 {
}
}
declare module TypeLite.Tests.TestModels.Namespace2 {
interface DifferentNamespaces_Class1 {
  Property1: string;
  Property2: string;
}
interface DifferentNamespaces_Class2 {
}
}

Comments (6)

  1. Paul O'Neill reporter

    Yep, at a module level that's the case. At at a class and identifier level it seems to be just ordered by discovery order.

    I've submitted PR 31 to try to at least help - it tries to order by module name, then class name, then field name. It should also allow custom formatters to get involved and do the sorting after they've run but there are some edge cases where it'll still be non-deterministically ordered (for example, if you wrote a custom module formatter that put everything in the same module).

  2. Ben Stull

    Sadly, this change broke anyone trying to use TypeLite to generate TypeScript classes that use inheritance. I know that TypeLite was built to create .d.ts files, but I've come across people (including myself) that use it to generate class definitions so they can easily extend their server models with functionality that the client needs rather than having to create a manually authored TypeScript class definition and keep it up to date with the generated interface.

    Before this change, I was able to explicitly order my .For<> statements to ensure base classes were generated before child classes. It's now impossible to order the output of objects in a way that doesn't break at runtime without renaming the objects so the hierarchy matches alphabetical order.

    Is this really that important? If not, it would be nice to revert this change.

    For now, I've create a private fork. I'd consider doing the work to give the option to generate class definitions (including ordering based on hierarchy) if project owners are ok with deviating from generating only definition files.

  3. Lukas Kabrt repo owner

    Sorry for inconvenience @Ben Stull . I see that with growing popularity I should pay more attention to the backward compatibility and to alternative use cases. I will look into this problem and try to make this behavior optional.

    If you want to extent TypeLite to give it the ability to generate class definitions I will be happy to collaborate. I am thinking of a new version of the library with better organized extension points and I'd like to hear what other users and developers miss.

  4. Favrbo

    I also need to support the issue that Ben Stull is mentioning. The fix for issue #82 also broke my solution, since I am using TypeLite for generating .ts file from .NET code.

    I did see, that Ben has made a pull request where this fix has been reverted. Just reverting is not the best option, since this would prevent my from updating TypeLite using NuGet for future changes (this was actually what caused my problem). I think this fix would be a great candidate for an optional feature. This would support a bigger audience and by disabling output ordering, I can fall back to setting the build order in my .csproj file.

    A better option would be to implement support for inheritance and ensure that base classes are added before derived classes. This might not be the main focus for the tool, but it is what we are using if for, and it would just make the tool better for a greater audience.

  5. Log in to comment