Things you should know before publishing a package on pub.dev
The internet is already full of articles on how to publish your package written in Dart language on the pub.dev, I’ve used them myself for publishing, but here I’d like to clarify some nuances that are usually not described in articles. These are the issues I’ve encountered personally, and I really wish I had known about them earlier. Let’s start at the beginning.
Do we need another package?
Let’s say you’ve created some neat UI widget for Flutter or wrote a new client for a fancy API. Cool, but think about it: does the community really need it? Please ask yourself a few questions:
1) My package has a unique functionality that other packages don’t have, and you can’t just achieve a similar result with a couple of new lines with these existing packages?
2) My package will be better covered by tests and documentation, more open to the community, and better supported than other existing packages.
3) My package supports all Flutter platforms as well as AngularDart and Shelf, etc.
If you answered “no” to at least one of these questions, then maybe, you should support other projects with issues/feature request filling or providing the feature or fix PRs?
I don’t want to discourage your eagerness but look at it practically, the Pub is already pretty packed with very similar projects, in your case, the chances of success will be greatly underestimated and there will be a lot of pitfalls on the way to release, which we will talk about in next steps.
Bureaucracy
Ok, looks like you are a stubborn person :). Let’s talk about what you’ll encounter before you’ve even written a single line of code.
Technically, publishing to the pub.dev is free and not that difficult (thanks to Google for that). With one caveat:
If you want your package to be taken seriously — you will need to create a verified account there.
And for this account, you must have a Google Account, which is connected to Google Search Console to your unique domain, which you are supposed to own, and finally, have access to the settings of its DNS. That’s quite a long chain of requirements, don’t you think?
So if you want to publish a package quickly, I recommend you first configure it all in advance, because this process can take several hours (due to the specifics of Google’s indexing). By the way, I also recommend you think about the publication strategy — because if you connect (or have already connected) the domain to your personal e-mail and publish the package via this account (with that domain), it means this personal e-mail will be publicly displayed in the publisher section of your package. And yes, this page is indexed and stored in Google cache, web archives, etc.). So, as you can imagine, you put this e-mail address at all risks you can have with an exposed e-mail address (spamming, phishing, etc.). Luckily there is a way around this — just add another member to the publishers and put his email as a contact e-mail (not your main, admin one).
Oh, and in addition, you have to provide the license. The lack of it reduces the number of pub points and makes it impossible to use the package in most organizations.
So, to create a verified account, you can use the official Dart guide:
plus, you may need a guide from your hosting, in my case, it was NameCheap.
As for the license, Google recommends BSD-3-Clause, because this is the type of license the Dart and Flutter teams use for their packages. But of course, most free licenses will also work.
Package listing
I want to say right away that
if you are going to put your library without any test coverage and/or without documentation — it’s a bad idea.
Your package will be at the bottom of the search list because the pub has three levels of scoring (there might be even more in the future). You can read more about them all at:
Likes and popularity are something, that comes organically over time, so you don’t have to worry about that at the time of publishing.
Pub points
Pub points, on the other hand, are something you can and should influence as a developer.
As you can see from the link above, you can check your score with the “pana” tool (but it can really modify your files as above, don’t forget to commit your changes before running it).
But there is another metric for 10 points which is checked additionally, on the servers when publishing, and that is “coverage by documentation”. But I’ll give you another tip: use the public_member_api_docs linter rule, to check the places that need to be covered by the documentation. And don’t be lazy to add usage examples, yep I understand that it’s quite boring, but here’s my next tip:
AI tools like ChatGPT, Githab Copilot, etc. handle this task quite well and quickly, so all you need to do is check what they have provided.
In addition, I advise you to run “dart doc” before publishing and check everything if you see the coveted message in the command line (“no issues found”).
Code coverage
As for test coverage, yes indeed, now the percentage is not checked in any way (please note that is not “yet” checked). But, firstly, high coverage almost automatically increases the package’s confidence, and secondly, if you can’t write tests for your code it probably means that you don’t really have time (at best) for this project, or it’s a sign of a bad code (at worst), but the result is essentially disrespect to the community (from my POV of course). And in fact, by adding tests for your code — you will permit other developers to test their code with your dependencies easily.
A handy mock (or interface for a mocking) is an invaluable gift to any user of your package.
The finishing touches
So you’ve written the code, tested it, covered it with documentation, included the recommended lint rules (at least), provided a minimum of nested dependencies, and put together a proper gitignore, instructions, and examples. All that’s left to do is publish your package, here are several tips you may need to know before you confirm publication:
1) It sounds weird, but it’s a fact: once published — you can no longer remove or hide the package from pub.dev, i.e. typo in the title for example will be there forever.
2) It’s worth starting with a semantic package version below v1.0.0, this way you can add checked badges, pub.dev links, fix any flaws in the number of pub points, etc., and only then roll out the first release sitting on a white horse.
3) Even if you don’t do the UI package — add a picture, for example, “code as a screenshot”. There are hundreds of free sites, IDE extensions, and tools for this on the internet. But be aware that this picture will not be visible in the documentation section or Pub at the moment if it’s listed in the markdown as a relative file link, you will have to use its full absolute URL to display it outside of your VCS repository (GitHub, GitLab, etc.)
4) Make your package easy to extend and use by other devs. Provide templates for Issues and PRs, guides on contributing to the project, instructions on reporting vulnerabilities, etc. And respond to the community on time, there’s nothing worse than a package with a dozen abandoned issues.
5) Is your package similar to Google’s? Ideally, compare your project with their repo so you can notice the differences and improve your code base (and your knowledge) with Dart’s best practices.
6) Finally, try your package out on some kind of live project with actual data, and ideally let other senior devs check it out.
That’s it, my dear readers, good luck in publishing your packages, if there is something I forgot, please let me know in the comments. You can also send me links to your published packages there, and I will try to check them too. Thanks for reading!
