Workiva / Workiva/dependency_validator
Support dependency_validator running on analysis_options.yaml files
Nobody has claimed this yet.
- Dominant language
- Dart
- Stars
- 66
- Forks
- 26
- Avg merge
- 5d 7h
- Merged PRs (30d)
- 7
Description
It is possible, and common practice to add a include: package:<somePackage>/<someEntrypoint>.yaml within an analysis_options.yaml file
For example, this is how pedantic and the newer lints package work
include: package:lints/recommended.yaml
Currently, dependency validator completely ignores this file, but it could, and probably should, audit the dependencies used within these files
I'm proposing the following rules regarding this file:
- if a dependency is used within the analysis_options.yaml
includestatement and is not declared within the pubspec.yaml file, the command should fail - if a dependency is only used within the analysis_options.yaml
includeAND is declared as a non-dev dependency, the command should fail
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing how dependency_validator reads pubspec.yaml and identifies dependency usage, then locate where analysis_options.yaml files are excluded. Use the include entry in analysis_options.yaml and the dependency declarations in pubspec.yaml as the verification cases. Done means undeclared includes fail validation and dependencies used only by the include are required to be dev dependencies.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- dart
- Domain
- cli, tooling
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100