Dependencies can be more than imports or used binaries
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
Direzione di ricerca
Inizia con le regole sulle dipendenze descritte nel README, in particolare il passaggio relativo agli import e all’uso degli eseguibili. Determina se le dipendenze esposte tramite tipi API inferiti o restituiti debbano essere rilevate, segnalate con un avviso o soltanto documentate; il lavoro è completo quando sono definiti un comportamento e la relativa validazione.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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.
}
- Lingua principale
- Dart
- Stelle
- 66
- Fork
- 26
- Merge medio
- 10h 59m
- PR unite (30g)
- 4
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di Workiva/dependency_validator
-
Glob workspaces supportAperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 35/100
Workiva/dependency_validator#176 · 2 reazioni ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 30/100
Workiva/dependency_validator#167 · 2 commenti ·
-
Support Doc ImportsAperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 45/100
Workiva/dependency_validator#153 · 1 commento ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
Workiva/dependency_validator#141 · 1 reazione ·
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 48/100
Workiva/dependency_validator#140 · 1 commento ·
Tutte le issue di Workiva/dependency_validator
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
AppFlowy-IO/AppFlowy#9075 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 67/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
avdept/JellyBoxPlayer#375 ·
I maintainer di solito rispondono entro 1 giorno
-
bug good first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
basictech01/uniun#300 ·
I maintainer di solito rispondono entro 1 giorno
-
Listener that removes itself in its callback causes other listeners to miss updatesForse già presa @RaphaelFakhri l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
RevenueCat/purchases-flutter#1962 ·
I maintainer di solito rispondono entro 1 giorno