Return type conventions

[zepumph]

In the doc it says:

Consider using explicit annotations for object literals and function return types even when they can be inferred.

[zepumph]

This was discussed during today's dev meeting about typescript conventions. Here are our decisions:

• We all felt like having explicit return types makes sense in all classes to ensure an API doesn't change. This is beneficial for common code and sims, in part because it helps replace the jsdoc.
• That said, you don't have to duplicate this for getter/setter methods AND their es5 getters and setters. For example, if there is a getX() method with an explicit return type, you don't need to provide the return type for the get x() getter too. It is up to the dev. That said, if we use this lint rule, we have to include them anyways: https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/eslint-plugin/docs/rules/explicit-function-return-type.md
• It is important to be explicit when defining the API, but using that API, it is best to infer, that reduces technical debt for refactors. This also applies for callback for generally.
  • For example using a scenery event listener, it is best to not duplicate those types in case IInputListener changes its API.
  • Also for internal, simple callbacks, it could be more harm than its worth to add types.

We want to start with https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/eslint-plugin/docs/rules/explicit-function-return-type.md.

[zepumph]

We currently spun up our own lint rule to just enforce on methods, not setters or getters. See

chipper/eslint/rules/explicit-method-return-type.js

Line 15 in 5cb8357

const exemptMethods = [ 'get', 'set', 'constructor' ];

. This has been working well for us. In the future, if we want to add getters and setters to the rule, we will. I don't think there is anything else for this issue.