Creating and Publishing a Flutter Package

Understanding CHANGELOGs

You’ve probably been in the situation of knowing there’s a new version of a package you use, but you:

1. Don’t know what the benefits of the upgrade are.
2. Don’t know what’s the effort for the upgrade.
3. Decided to upgrade but are having trouble with some missed property or function.

When you run into this situation, look at the ChangeLog tab:

But today, you’re the creator, not the user. It’s your job to ensure your users won’t be helpless when going through this same situation. You do that by creating a thoughtful CHANGELOG.md file.

Unlike the freestyle of the README, this one follows a specific format:

1. One heading for each published version. The headings can be level 1 or level 2.
2. The heading text contains nothing but the version number, optionally prefixed with “v”.

Here’s an example of a typical raw CHANGELOG and here’s what your users will see.

Adding a CHANGELOG File

Replace the empty CHANGELOG.md under your project’s root with the one in the starter/auxiliary folder from the downloaded materials.

Notice that your CHANGELOG contains a single entry: 1.0.0. One concern you can expect to have in your next ventures is knowing how to name your subsequent versions: 1.0.0+1? 1.0.1? 1.1.0? 2.0.0? Technically, you can do whatever you want, but it’s good pub.dev citizenship to follow this standard:

When you increase a number, the others to the right should be zeroed. For example, if you both add a feature and fix a bug, you increase the middle number and set the next to 0.

You’re finally ready to claim your piece of real estate on pub.dev. :]

Publishing Your Package

The introduction of this article listed several reasons to create a package. Now, to even things out a bit, take this delicate disclaimer to heart:

If you still want to take this road and become a package parent, the only thing you’ll need is a Google account. If you’re still not sure, don’t fret! Consider the next two steps a rehearsal.

Delete the example/build directory to guarantee your package won’t go over the pub.dev limit of 10 MB after gzip compression. That folder is automatically ignored if your project is in a git repository where the .gitignore includes build/ — which likely will be your case when publishing a package of your own.

Open your Android Studio’s shell again by clicking Terminal at the bottom of your screen. Run the following command:

dart pub publish --dry-run

The command then outputs a tree of the files in your package. If the command gave you a Package has 0 warnings. message, it’s the end of rehearsal for you! You can still execute the next steps to try publishing Focus Detector, but expect an error at the end because the package already exists.

For the real thing, run pub publish (without the --dry-run part). After outputting the file tree, the command will warn you that publishing is forever and prompts you to confirm before proceeding. Type y and press Enter. Next, it’ll ask you to open a link in your browser and sign in with your Google account. After signing in, the command will automatically verify your authorization and start the upload.

If you’re trying to publish Focus Detector, you’ll receive a Version 1.0.0 of package focus_detector already exists. error message. If you’re publishing a package of your own, wait a couple of minutes – or don’t, if you’re too anxious – and try accessing your new package’s URL:

https://pub.dev/packages/YOUR_PACKAGE_NAME

Welcome to the club pub!

Understanding Verified Publishers

When you publish a package, your pub.dev page displays your email address to everyone. This not only lacks privacy but may also look unprofessional to users – who knows you’re not some random account? The way around this is to be a Verified Publisher. This works as “your company” on pub.dev, where your Google account is just an employee uploader. All you need is a domain address.

Another great advantage is the credibility boost you get from having a verified publisher badge everywhere your name appears on pub.dev:

If you want to become a verified publisher, read more here.

Using the Remote Package

Now for the easy part. Go back to the Yes We Scan project you haven’t opened since the beginning of the article.

Double-click pubspec.yaml in the left panel and replace visibility_detector: ^0.1.5 with focus_detector: ^1.1.0+1 — which is the current version of Focus Detector, and not the 1.0.0 you just fake published. Download the new dependency with Pub get.

Open lib/pages/scanner_page.dart, and, at the top of the file, replace:

import 'package:yes_we_scan/utils/focus_detector.dart';

with:

import 'package:focus_detector/focus_detector.dart';

Done! Now you’re depending on the version hosted on pub.dev and can delete the lib/utils/focus_detector.dart.

As your last task, build and run the project to make sure everything is safe and sound.

Where to Go From Here?

Download the completed project files by clicking the Download Materials button at the top or bottom of the tutorial.

You couldn’t be more prepared to create your own package. If you don’t have an idea to invest in, check these issues labeled by the Flutter team as “would be a good package”. They do this to encourage us to develop the features they consider outside of the framework scope.

We hope you enjoyed this tutorial. If you have any questions or comments, please join the forum discussion below!