Keep tags of tagged unions at beginning.

[ForkKILLET]

Language

Typescript

Input

type TaggedUnion =
  | { type: 'number', a: number, b: number }
  | { type: 'string', z: string, y: string }

Expected output

I think keeping tags of tagged unions at beginning (and perhaps sort by the tag?) would be sensible in this situation.

type TaggedUnion =
  | { type: 'number', a: number, b: number }
  | { type: 'string', y: string, z: string }

Actual output (or error message)

type TaggedUnion =
  | { a: number, b: number, type: 'number' }
  | { type: 'string', y: string, z: string }

[k2snowman69]

@ForkKILLET Can you fill out the https://github.com/snowcoders/sortier/blob/main/.github/issue_template.md I'm not sure why it doesn't prefill it by default anymore. I don't quite understand what you are asking so an example would really help

[k2snowman69]

@ForkKILLET Attempting again, keep me posted

[ForkKILLET]

@k2snowman69 Sorry for the late reply. Just edited the issue. 🫡

[k2snowman69]

What about something like this:

type TaggedUnion =
  | { type: 'number', a: number, b: number }
  | { type: 'string', z: string, y: string, a: null | string | number}

Would the expected output be something like:

type TaggedUnion =
  | { a: number, type: 'number', b: number }
  | { a: null | string | number, type: 'string', y: string, z: string }

Or something else?

[ForkKILLET]

Hmm, so I guess the question is how to detect which field is the tag.

A possible rule could be:

• A tag should appear in all union branches;
• Its type should be a literal type.

Under this rule, a in your example won't be considered a tag.

Additionally, we could provide a configuration option where users can specify possible tag key names (e.g. ["type", "tag", "status"]), so that fields like a won't accidentally be treated as tags.

If multiple keys still match the tag rule, I think the output you've given (tags sorted followed by other fields sorted) is reasonable.

[k2snowman69]

I would say I'm more of a fan of the configuration option as you just defined quite a few requirements and I can see myself getting bugs when someone accidentally comes across it unexpectedly. The configuration option makes it more clear what someone intends to override and causes less forking in the code base.

I'm debating between a separate config option (ex. js.promotedKeys or if we can come up with a better name) or extending js.sortTypeAnnotations to be able to handle random strings. I would intend for this to override not just union types but all object like structures and the keys provided in this list would always get pushed to the beginning of the object in the order provided in the configuration.

[k2snowman69]

Let me know if this is something you'd like to pursue and open a PR for. I think my preference would be for js.sortTypeAnnotations to be able to handle random strings but I'm not sure what to do about collisions of named objects and random strings, I'm open to ideas. I think we can use js.promotedKeys as a plan b if plan a doesn't work.