Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Dependencies can be more than imports or used binaries

Abierto
#6 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
dart
Área
tooling

Línea de trabajo

Comienza con las reglas de dependencias descritas en el README, especialmente el pasaje sobre las importaciones y el uso de ejecutables. Determina si las dependencias expuestas a través de tipos de API inferidos o devueltos deben detectarse, generar una advertencia o solo documentarse; el trabajo estará terminado cuando haya un comportamiento definido y la validación correspondiente.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

From the README:

Some packages are not imported by any dart files but are used for their executables.

Based on this sentence I'm assuming that only import statements are found programatically. There is another way that a dependency can sneak in that you might want to consider, or at least warn in the readme so it can be treated the same way as executables.

If a class is returned from an API that isn't defined in the package, you can silently be depending on a method signature defined in some other package that you might not import.

import 'package:b/b.dart' as b;
// no import to package:c

void main() {
  b.someBMethod().someCMethod();
  // If someBMethod returned a class from C I have an implicit dependency on C
}

Here package:b could plausibly move to a new version of package:c without a breaking change version bump.

With type inference this 'type leaking' can happen in sneaker ways:

import 'package:b/b.dart' as b;
// no import to package:c

void main() {
  // Assume someBMethod has the signature: int someBMethod(C c)
  var x = someBMethod;
  x = (value) => value.someCMethod();
 // due to type inference I got autocomplete and would now break if someCMethod is renamed.
}
Lenguaje dominante
Dart
Estrellas
66
Forks
26
Merge medio
37 min
PR fusionados (30 d)
1

Preparar el entorno

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.

Más de Workiva/dependency_validator

Todos los issues de Workiva/dependency_validator

Issues similares

Más issues de Dart

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.