loopbackio / loopbackio/loopback-next

eslint: forbid boolean function arguments

Ouverte
#4,674 6 commentaires 0 réactions 1 personne assignée Voir sur GitHub

@achrinza y travaille déjà.

Depuis le 2/12/2021.

breaking-change feature good first issue Internal Tooling
Langage dominant
TypeScript
Étoiles
5.1k
Forks
1.1k
Merge moyen
2 j 21 h
PR mergées (30 j)
27

Description

Function arguments of type boolean are considered as a bad practice because they make the code difficult to read and reason about.

Consider the following code:

ctx.getBinding('repositories.todo', true);

What does the true flag mean? There is no way to tell when reading the code using the function, we have to look up the API definition and/or implementation to understand.

Compare with the current implementation which is following the best practices:

ctx.getBinding('repositories.todo', {optional: true});

Now it's more clear that we want to treat the binding as optional and don't trigger an error when it's not found.

Let's improve our eslint configuration to automatically detect and reject boolean arguments. Eslint rule to use: no-inferrable-types

Further reading:

Acceptance criteria

  • A commit modifying our eslint configuration to enable the new check. This is a breaking change, see Describe incompatibilites for release notes
  • One or more commits fixing any violations of this new rule in our existing code. For functions (methods) that are part our public API, decide whether to disable this rule via a code comment, change the method signature in a breaking (semver-major) change or implement both variants (with an options arg, with a boolean arg for backwards compatibility) to avoid a breaking change.

Breaking changes must be committed in such way that they don't trigger semver-major release of packages that are not affected.

Guide de contribution

Ouvrir le guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Évaluation

Cette issue n'a pas encore été évaluée.

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.