dart_apitool updates
dart_apitool updates
Recently dart_apitool got 2 significant updates. Thanks to all the contributors that made that possible.
1. More robust preparation step
dart_apitool makes local copies of the packages it analyzes
When dart_apitool analyzes packages it has to do some preparation steps in order to make sure the analysis run doesn’t have any issues:
- it has to remove any
analysis_options.yaml
because this file can limit the scope of the analyzer.
This is OK if you want to e.g. exclude files from linting but dart_apitool needs to see all of your files to create a complete model of your public API. - it has to remove an example project as it needs to run
pub get
to get the dependencies prepared and up-to-date for a successful analysis run.
Some packages have examples bundled with them that sometimes reach into packages via relative paths that live outside the package directory. Those paths are valid inside the package’s repository but are not valid outside of it. A dart_package bundles those examples which means they also live inside the downloaded package and might have invalid relative path dependencies.
As dart_apitool is not interested in those examples it can just remove them from the package directory and runpub get
to get the dependencies.
To not interfer with a local copy of the package (in the pub cache or on disk) dart_apitool makes a temporary copy of the package before manipulating it.
why this is complex and created an issue
This works really well. In the past there has been a special issue if a package was referenced on disk and contains relative path depdendencies. To solve that issue dart_apitool had a functionality to analyzse those path dependencies to determine the directory structure it needs to copy to the temporary directory making the relative path dependencies still work.
In the meantime dart (or better: pub) has a new feature: pubspec_overrides.yaml
.
This is a separate file that can be used to override dependencies in a pubspec.yaml
. As dart_apitool only looked into the pubspec.yaml
it didn’t see those overrides and therefore didn’t know about the relative path dependencies that might be defined in there.
A potential solution to that would have been to also parse the pubspec_overrides.yaml file and take the dependencies defined in there into account.