Beyond alphabetic ordering or methods and properties

[brian428]

It looks like the API docs always list the properties and methods in alphabetical order. It would be nice to have a configuration option to change this so things are listed by access modifier (static public/static protected/static private/public/protected/private).

Thoughts?

[FlippieCoetser]

Yes, Please!

[sebastian-lenz]

The entries of the documentation are currently grouped by kind and then sorted by static state and name. Of course we can add new ways of grouping and sorting.

[brian428]

Yeah, this obviously isn't a critical issue or anything. We do have the option to filter to see only public, or public and protected as well. I just thought it would be helpful to be able to see all the elements, but organize them a bit more.

Thanks again for the great work on Typedoc. We all know it's hard to overstate how useful good API docs are!

[jrieken]

I have a single d.ts file and I would prefer the sorting to be the order in which symbols are defined in source.

[kristiyanP]

I wonder if this issue got any follow up?
Is it now possible to sort the entries?
Would be much more readable if the entries were sorted by first not optionals and then optionals.
Any insight on how to achieve this?
Thanks

[Gerrit0]

This could be achieved by modifying the default theme to sort before rendering. I'm not aware of any implementation, but it shouldn't be that difficult to do.

[kristiyanP]

Thank you, I will look into it.
I still do believe that this should be the default behaviour... When reading a public API you are most interested in what is required and not what is optional.

[kristiyanP]

For example:
https://typedoc.org/api/interfaces/typeparametercontainer.html#flags

The fact that flags, id, kind,name,originalName parameters are required is not clear at all.
A well defined API would first give priority to the required fields and then the optionals.
Maybe also group them in two categories.

[azinit]

Still actual!)

[jankuca]

It would be great to have the option to preserve the original method/property order.

[SukkaW]

Is the issue still going on?

[vegather]

It's coming up on the 6 year anniversary of this issue, any chance it can be added to the list of features for v0.21?

As a library author, I put care into the order my properties and methods are declared. The most important stuff to a user of my library goes to the top, related properties are close together, etc. I also like to use a single config object instead of multiple arguments to achieve named arguments, similar to how axios does it. As these are objects with properties, the properties are sorted alphabetically instead of the order I put them in, effectively sorting my function arguments alphabetically.

It would be really great if my API documentation reflected the level of care I have put into library itself.

[edqx]

Also would be nice if I could order enum methods by their value rather than alphabetically by their name, but I don't know if this is out of scope of typedoc.

[Gerrit0]

I wasn't planning on doing this in 0.21, primarily because I hadn't come up with a flexible way of making this configurable without resulting in a ton of wasted time writing a bunch of custom sort functions... I think I've now figured one out.

The plan:

• Add a new option sort which is an ArrayDeclarationOption
• Sort options may apply to all reflections, or only some of them.
• Sort order will be applied with descending priority. With the setting ["static-first", "visibility"], TypeDoc will first compare two reflections by if they are static or not, and if that comparison returns equal, will check the visibility of each reflection. On the other hand, if ["visibility", "static-first"] is specified, TypeDoc would sort all public properties first and then sort each group to put static properties first. This means that ["source-order", "static-first"] is equivalent to ["source-order"] since ordering by position in source will always produce a non-equal comparison.

Planned ordering options:

• source-order (sorts by file, then position in file)
• alphabetical
• enum-value-ascending (only applies to children of an enum)
• enum-value-descending (only applies to children of an enum)
• static-first
• instance-first
• visibility (public, then protected, then private)
• required-first

I think this gives a pretty flexible option, without resulting in a horrible mess to maintain... Thoughts?

[vegather]

Hi @Gerrit0 , thanks for looking into this!

That plan sounds awesome! Provides all the flexibility I think I would ever need, and then some 👌

Also, sorry if my last comment was a bit harsh. I was just frustrated after having spent a ton of time looking for viable alternatives. This remains my favorite documentation tool for TypeScript! Thanks for all the hard work you've put into this project! 🚀