Class Member Ordering (TypeScript/Flow)

[Coder-256]

Prettier 1.15.1

Input:

class Foo {
  baz: number[] = [123, 456, 789];

  printInstance() {
    console.log("Instance members:", this.bar, this.baz);
  }

  protected static myStatic = "I'm a field!";

  constructor(hello: string) {
    this.bar = hello.length;
  }
  static secondStatic = { id: "someID", value: "foo" };

  bar: number;
  static printStatic() {
    console.log("Static members:", Foo.myStatic, Foo.secondStatic);
  }

  bazCount() {
    return this.baz.length;
  }
}

Output:
Same as the input.

Expected behavior:
There is a more-opinionated way to define the order of class members. For example, a more readable output is: (Statics First; see below)

class Foo {
  protected static myStatic = "I'm a field!";
  static secondStatic = { id: "someID", value: "foo" };

  static printStatic() {
    console.log("Static members:", Foo.myStatic, Foo.secondStatic);
  }

  bar: number;
  baz: number[] = [123, 456, 789];

  constructor(hello: string) {
    this.bar = hello.length;
  }

  printInstance() {
    console.log("Instance members:", this.bar, this.baz);
  }

  bazCount() {
    return this.baz.length;
  }
}

However, there are a variety of ways for how class members should be sorted... (by access level, by method vs property vs constructor, combinations of those, etc.). In keeping with Prettier's opinionated Option Philosophy, these members should be ordered in a defined way if not configurable. However, TypeScript's TSLint rule member-ordering gives three ways:

• Fields First: Static/instance fields, the constructor, then static/instance methods. This switching static, instance, static, instance pattern seems confusing to me as it separates static fields from static methods and instance fields from instance methods.
• Instance Sandwich: Same as Fields First but static methods come after instance methods. This just seems outright confusing, and it further separates static members, but sandwiches the instance members (as the name implies).
• Statics First: Static fields/methods, instance fields, the constructor, then instance methods. This makes the most sense to me because the static members are kept together, and so are the instance members, separated only by the constructor (which initializes the instance fields that are right above it).

I understand that there may be conflicting opinions on these orders, but it is simply important for Prettier to specify a single, opinionated way that members should be ordered. The less configuration, the better, and providing options here defeats the purpose of Prettier. Nevertheless, whether or not class member formatting should be optional or required is another point to consider, and so is the treatment of computed getters as fields or as methods.

[lydell]

Hi! People have asked for:

• Sorting imports
• Sorting object keys
• Sorting JSX properties
• Sorting CSS properties

…in the past, but we've decided not to do sorting.

• Sorting is sometimes unsafe. Prettier tries really hard to be completely safe to run.
• Changes the AST too much, which is something Prettier does not do, to limit its scope and to be able to easily verify that running Prettier on a piece of code does not change its meaning.