Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

eslint member-ordering trap - whichever declaration comes first causes an error

I've got this code:

export class RouteParamsService {
  private routeParamsChangeSource = new ReplaySubject<Params>() // lets call this line 1
  routeParamsChange$ = this.routeParamsChangeSource.asObservable() // lets call this line 2
  ... etc
}

If I put line 1 before line 2 I get the error:

@typescript-eslint/member-ordering Member routeParamsChange$ should be declared before all private instance field definitions

If I put line 2 before line 1 I get the error:

Property routeParamsChangeSource is used before its initialisation

I understand both errors and why I am getting them. However, is there a rule that will relax the rules BUT ONLY when you end up in a trap like this? I know I can do eslint-disable-line @typescript-eslint/member-ordering but I don't want to have to do this everytime I hit this issue (which I am hitting a lot).

I also DO NOT want to make routeParamsChangeSource public.

Any ideas? thanks

like image 688
danday74 Avatar asked Jan 30 '21 03:01

danday74


People also ask

What is the purpose of member declaration order?

Requires a consistent member declaration order. A consistent ordering of fields, methods and constructors can make interfaces, type literals, classes and class expressions easier to read, navigate, and edit. This rule aims to standardize the way class declarations, class expressions, interfaces and type literals are structured and ordered.

What are ESLint rules and how to use them?

Rules in ESLint are grouped by type to help you understand their purpose. Each rule has emojis denoting: enforce "for" loop update clause moving the counter in the right direction. disallow using Object.assign with an object literal as the first argument and prefer the use of object spread instead.

What is ESLint unexpected console statement?

The lint message: ESLint: Unexpected console statement. (no-console) During the development phase, you may leave some console.log comments. logging to the console is a side effect (more about side effects in the last part of this article). If you insist to keep them, just remember to disable these to avoid lint error;

Is “defined but never used” a lint error?

So change; “defined but never used” is not a lint error but a warning. Let’s talk about side effects. A side effect is a state change that is observable outside the called function other than its return value.


1 Answers

The @typescript-eslint/member-ordering lint rule does not currently understand dependencies between fields.

As you can understand - this sort of dependency creates a complex ordering problem, which nobody from the community has yet been motivated enough to solve.

You can see the issue tracking it here: https://github.com/typescript-eslint/typescript-eslint/issues/2882

The project welcomes contributions - if this is a problem that is important to you.


As for actual workarounds or fixes.

Disable comments are a good temporary measure.

Another alternative is to move the dependencies into the constructor:

export class RouteParamsService {
  private routeParamsChangeSource = new ReplaySubject<Params>();
  routeParamsChange$;

  constructor() {
    this.routeParamsChange$ = this.routeParamsChangeSource.asObservable();
  }
}
like image 129
Brad Zacher Avatar answered Sep 24 '22 04:09

Brad Zacher