Pub isn't just for using other people's packages. It also allows you to share your packages with the world. If you have a useful project and you want others to be able to use it, use the pub publish command.
We support the following search expressions:
"exact phrase": By default, when you perform a search, the results include packages with similar phrases. When a phrase is inside quotes, you'll see only those packages that contain exactly the specified phrase.
package:prefix: Searches for packages that begin with
prefix. Use this feature to find packages in the same framework.
dependency:package_name: Searches for packages that reference
package_namein their pubspec.
dependency*:package_name: Searches for packages that depend on
package_name(as direct, dev, or transitive dependencies).
email:firstname.lastname@example.org: Search for packages where either the author or the uploader has the specified e-mail address.
NOTE: The Pub scoring model is under development, and is subject to change.
The popularity score—representing how often a package is used—is derived from download statistics. Although this score is based on actual download counts, it compensates for automated tools such as continuous builds that fetch the package on each change request.
How can you improve your popularity score?
Create useful packages that others need and love to use.
The health score is based on static analysis of the package with
(*) Percents are applied with cumulative multiplication.
For example: 2 errors and 1 warning will get a score of 53, because:
(0.75^2 * 0.95 = 0.534375).
How can you improve your health score?
flutter analyze in case of Flutter),
and fix the items it returns (especially errors and warnings, hints barely
decrease the health score).
to specify further linter rules, and make sure you fix all warnings and errors before publishing.
Here's an example
# https://www.dartlang.org/guides/language/analysis-options # Source of linter options: # http://dart-lang.github.io/linter/lints/options/options.html linter: rules: - camel_case_types - hash_and_equals - iterable_contains_unrelated_type - list_remove_unrelated_type - unrelated_type_equality_checks - valid_regexps
The maintenance score reflects how tidy and up-to-date a package is. Here are some of the factors that influence this score:
analysis_options.yaml: Best if this file is present. For more information, see Customize Static Analysis.
How can you improve your maintenance score?
Click your package's overall score to see the Analysis page, which has suggestions for improving the package's score. Fix them, and release at least one new version every year to keep your maintenance score up.
You can find the overall score either near the top of the package's page or to the right of your package in any listing on this site. To get suggestions before publishing, run pana manually.
The overall score is a weighted average of the individual scores:
Default listings use composite scoring to sort packages. The score is based on the overall score, and if applicable, the platform specificity and the text match score is also factored in.
Each package's overall score is visible at the side of the results, regardless of the sort order.