loopbackio / loopbackio/loopback-next

eslint: forbid boolean function arguments

Abierto
#4,674 6 comentarios 0 reacciones 1 asignado Ver en GitHub

@achrinza ya está trabajando en esto.

Desde el 2/12/2021.

breaking-change feature good first issue Internal Tooling
Lenguaje dominante
TypeScript
Estrellas
5.1k
Forks
1.1k
Merge medio
2 d 21 h
PR fusionados (30 d)
27

Descripción

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.

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Evaluación

Este issue todavía no se ha evaluado.

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.