August 2, 2021
Publishing Dart and Flutter packages at pub.dev - Part 2
Welcome to the sequel of the Dart and Flutter package creation article. In the previous read you learned how to write and publish a package at pub.dev. Now it’s time to work on the quality of the environment in which our package will live by working on the GitHub repo. If you’re looking for a practical example, make sure to check out the equations package repository.
Ecosystem quality
When you create a package, you shouldn’t only strive for the highest content quality of the lib folder. You should really write a lot of tests inside test to ensure that the lowest possible number of bugs appear in your code. In particular:
Make sure to format your code using Dart format or Flutter format;
Make sure to set up rules as much as possible in your analysis_options.yaml file (look at the official lint and flutter_lints` packages);
Make sure to write unit tests;
Make sure to write widget tests for your widgets (if any);
Make sure to write golden tests for your widgets (if any).
Placing an example folder at the root of your package, other than giving you pub points, is very important because it can quickly give the users an idea of which features your package contains. For instance, the example folder of my equations package has the following contents:
A dart_example/ folder with some “pure” Dart examples on how to solve equations with the package;
A flutter_example folder with a complete, working equation solving app (made with Flutter, of course!);
A README.md file that summarizes the contents of the folders and gives a quick preview.
The inline documentation is important and so are working examples to play with. The most beautiful part of this is that we can use Flutter web and GitHub pages to deploy and run our example so users can immediately play with it! No need to download files or install files on their mobile devices.
https://albertodev01.github.io/equations/
If quality really matters for you, then aiming for a high coverage percentage is a must. While 100% code coverage is not always possible, I would say that 85% should be the real minimum you should impose. We’re going to see in a bit how to generate a coverage report with Flutter and link it to GitHub.
GitHub actions
Setting up a GitHub action for your Dart package (or “project” to be more generic) is very easy: you just need to create the .github/workflows/ hierarchy in your repository’s root and then add the action itself. For Dart, you can use this setup:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
name: dart_ci
on:
push:
branches:
-master -
develop
jobs:
verify_dart_project:
name: Dart CI action
runs - on: ubuntu - latest # it could also be 'macos-latest'
or 'windows-latest'
steps:
-name: Checkout
uses: actions / checkout @v2 -
uses: dart - lang / setup - dart @v1
-
name: Installing the dependencies
run: dart pub get
-
name: Making sure the package is formatted
run: dart format--set - exit -
if - changed.
-
name: Making sure that there are no analysis warnings or errors
run: dart analyze--fatal - infos--fatal - warnings
-
name: Running unit tests
run: dart test--coverage = coverage && dart run coverage: format_coverage--lcov--in = coverage--out = coverage / lcov.info--packages = .packages--report - on = lib
-
name: Making sure that code coverage is at least 95
uses: VeryGoodOpenSource / very_good_coverage @v1 .1 .1
with:
min_coverage: 95 # You can lower or raise this value, but
try to keep it as high as possible!
With this action, every time you push to the main or develop branches the CI pipeline controls your package (formatting, static analysis, tests) and ensures that the coverage satisfies a minimum threshold. If every step successfully executes, a green tick is appended next to your commit record on GitHub.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
-name: Making sure that code coverage is at least 95
uses: VeryGoodOpenSource / very_good_coverage @v1 .1 .1
with:
min_coverage: 95
-
name: Uploading coverage to Codecov
uses: codecov / codecov - action @v1
with:
token: {
{
secrets.CODECOV_TOKEN
}
}
I always use these two steps together because I really like the coverage reports made by codecov.io. Note that the above action only works on “pure” Dart projects. If you need a Flutter action, then you may want to take inspiration from this one instead:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
name: flutter_ci
on:
push:
branches:
-master -
develop
jobs:
verify_flutter project:
name: Flutter CI action
runs - on: macos - latest # it could also be 'ubuntu-latest'
or 'windows-latest'
steps:
-name: Checkout
uses: actions / checkout @v2 -
uses: subosito / flutter - action @v1 .5 .3
-
name: Installing the dependencies
run: flutter pub get
-
name: Making sure the package is formatted
run: flutter format--set - exit -
if - changed.
-
name: Making sure that there are no analysis warnings or errors
run: flutter analyze--fatal - infos--fatal - warnings
-
name: Running unit and widget tests
run: flutter test--coverage
-
name: Making sure that code coverage is at least 95
uses: VeryGoodOpenSource / very_good_coverage @v1 .1 .1
with:
path: example / flutter_example / coverage / lcov.info
min_coverage: 95
I generally use this setup with the working-directory: example/flutter_example addition to make sure that CI executes the action inside the example folder where my Flutter project actually lives. Click here if you want to see how I set up the entire CI pipeline for my package.
Bonus!
As I told you earlier, there’s the possibility to deploy the web version of your Flutter app using GitHub pages and this is awesome! In order to do it, I simply use this action:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
name: example_web_deploy
on:
push:
branches:
-master
jobs:
flutter_web_example_deployment:
name: Equations example - Flutter web deployment
runs - on: ubuntu - latest
defaults:
run:
working - directory: example / flutter_example
steps:
-name: Checkout
uses: actions / checkout @v2 -
uses: subosito / flutter - action @v1 .5 .3
-
name: Installing the dependencies
run: flutter pub get
-
name: Building
for the web
run: flutter build web--csp
-
name: Setting the git username
run: git config user.name github - actions
-
name: Setting the git email
run: git config user.email github - actions @github.com
-
name: Adding web source
run: git--work - tree build / web add--all
-
name: Adding a commit message
run: git commit - m "Automatic deployment by github-actions"
-
name: Automatic web deployment
run: git push origin HEAD: equations_web--force
Every time I push something into master the equations_web branch is automatically updated (and created, if it doesn’t already exist) with the web build of my Flutter app. I just need to make sure that GitHub pages point to the correct branch and the example is immediately online:
The --csp flag is generally not required when building with Flutter build web but in certain cases you’d need it (for example, if you’re using FlutterFire plugins you’ll very likely need it).
References
Flutter Complete Reference book
The official Dart Tour guide
LOOKING TO EARN?
Check out Topcoder Freelance Flutter Gigs.