One of the ways to “encourage” developers to write tests is to have a code coverage check as part of the Continuous Integration (CI) process. Some teams even set an ambitious goal of achieving a 100% code coverage threshold, which, in my opinion, is often not worth the effort. While it can serve as an impressive metric for developers to showcase to their managers, it does not necessarily ensure the absence of bugs. In fact, it may provide a misleading sense of security.

Module-based Threshold Concept

In this article, I shared a clean approach to separating your app into modules. The GitHub repository already includes various tests and CI checks.

Let’s enhance it further by ensuring that, in addition to running unit tests, we also collect code coverage data and verify that it exceeds the specified thresholds.

The concept is that different modules can have varying thresholds. For instance, the domain module, which contains more business logic than the others, should be tested more rigorously. For the sake of the fun, let’s aim for 100% there in this module. Conversely, for the presentation module, we might set a lower target threshold, let’s make it just 40%. Typically, BLoCs/Cubits are tested more thoroughly than widgets/screens. Other modules may not have a specific target threshold. In practice, this means setting the threshold to 0%, allowing the check to pass regardless of the coverage value.

Implementation

The most useful tool for running tests with varying code coverage thresholds is very_good_cli.

With a command like very_good test --coverage --min-coverage 100, we can easily validate the coverage.

The question is how to apply this based on the module. The most straightforward approach for me is to create a special file in the test folder of each module where a custom threshold is specified. Then, we can use a small script that reads the threshold from the file and passes it to the very_good test command. I named this script test_with_coverage.sh and placed it in the scripts folder.

With Melos we can easily invoke the script for each of the intended modules.

All the changes required to set this up are detailed in this small PR.

Conclusion

In summary, by leveraging tools like very_good_cli, Melos, and custom scripting, we can ensure that each part of the application is tested according to its specific needs. This approach provides a balanced and practical testing strategy.

Resources

GitHub - Pavel-Sulimau/flutter_modularized_di: Modularized Flutter Counter App Honoring Clean Architecture Principles and Using Simple DI Abstractions to Preserve Encapsulation within Modules.

Flutter: Module-based Code Coverage Thresholds was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

Having experienced the incredible scale and excitement of FlutterCon 2023, I knew attending Fluttercon Europe 2024 was a must for me. This year, my excitement was heightened as I participated not only as an attendee but also as a speaker!

In this article, I’ll share some insights from the presentations I attended. Although I couldn’t catch all the talks in real time, I plan to watch the recordings of the other sessions once they become available.

Day 1 — July 3

Opening Keynote by Andrew Brogdon

9:00 AM — Widget Way

Andrew provided an overview of Flutter’s current state, its roadmap, and the potential influence of Generative AI on its future. He also discussed Flutter’s impact on large companies and explored ways to create more opportunities.

Zero runtime errors: Exploring Static Code Analysis techniques in Flutter by Daria Orlova

10:20 AM — Async Area

Developers typically favor developing new features over troubleshooting bugs, yet bugs are an inevitable aspect of software development. Static code analysis presents a proactive approach by detecting potential errors before the code is compiled, thereby streamlining the development process and boosting productivity. This talk provides comprehensive guidance on how to effectively implement static code analysis in your project.

Showing that you care about security — OpenSSF Scorecards for Dart and Flutter projects by Chris Swan

11:15 AM — Async Way

Google uses OpenSSF Scorecard badges on Dart and Flutter repositories to highlight the commitment to security through various practices like dependency pinning and branch protection. This presentation will guide you on applying these security measures to your Dart and Flutter projects, covering the initial setup in a repository, expanding it across multiple repositories within an organization, and automating the maintenance of these security practices to reduce manual effort.

Navigation in Flutter — the not-so-obvious parts by Matej Rešetár

12:10 PM — Widget Way

Just use go_router with go_router_builder and you’re good to go :) If you are not satisfied with it, consider using auto_route. That’s pretty much it.

Realtime Communications with Flutter by Simon Lightfoot

1:40 PM — Widget Way

Discover how to overcome Firebase/Firestore limitations in Flutter projects by switching to a backend written purely in Dart.

One Size Doesn’t Fit All: Tailoring Flutter Architectures for Team and Business Success by Jan Stępień

3:15 PM — Flutter Forest

In the startup environment, Jan learned to balance ideal long-term architecture with the immediate needs of the business by adopting a pragmatic approach, prioritizing features, and refactoring gradually, so he shared his insights on the topic.

Code Quality Gates for Large-Scale Flutter Apps by Pavel Sulimau

3:45 PM — Flutter Forest

Well, this was a talk I simply couldn’t miss attending, given that I was the presenter! I endeavored to pack as many guidelines and tools as possible into 20 minutes, aiming to ensure that attendees could set a higher code quality standard for their projects.

Compilers, Virtual Machines, and Code Analysis — What makes Dart and Flutter run by Norbert Kozsir

4:20 PM — Dart Gen

This session dived into the mechanics behind Flutter, focusing on the Dart compiler, DartVM, Dart Analyzer, and the Engine, beyond everyday coding practices.

Debugging performance issues with the Flutter DevTools by Alexandre Moureaux

5:20 PM — Widget Way

During this live-coding session, we addressed performance issues in a dummy app through real-life examples and utilized the performance view in the DevTools to guide our process.

Day 2 — July 4

Android Platform Views Past, Present, Future by John McCutchan

9:20 — Dart Den

That was an insightful exploration into how Platform Views are implemented on the Android platform, including their advantages and disadvantages.

Dart FFI: A Beginner’s Guide to High-Performance Integration by Matteo Maria Terzuolo

10:15 AM — Async Area

Dart FFI lets you enhance your Dart applications by calling functions from languages like C or Rust, ideal for tasks needing extra performance such as image processing or machine learning. This talk explored the benefits and challenges of using Dart FFI, as well as alternative approaches to enhance your app’s performance.

Building Real-Time Audio/Video Apps with Flutter and WebRTC by Masahiro Aoki

11:10 AM — Async Area

This session provided a comprehensive guide to creating real-time audio and video communication applications using Flutter and WebRTC. It covered a range of topics from basic to advanced concepts.

Demystifying App Architecture: The LeanCode Guide by Mateusz Wojtczak and Marcin Chudy

1:25 — Dart Gen

LeanCode has developed more than 40 Flutter apps, each presenting unique challenges and opportunities for learning. The talk explored their preferences in state management and other practices, encouraging attendees to understand the reasoning behind their choices and how they minimize redundancy in development.

Self-host private pub packages by Pascal Welsch

2:20 PM — Widget Way

Their Flutter agency encountered difficulties in sharing packages across projects because of the significant costs and maintenance challenges associated with self-hosting Dart and Flutter packages. In this talk, Pascal discussed how they discovered a cost-effective method to host their own pub repository, including utilizing their own domain. Moreover, they offered it as an open-source solution to the Flutter Community without any sponsorship.

Presentation events — a missing piece in BLoC by Marcin Wojnarowski

3:30 PM — Widget Way

This talk explores how to incorporate presentation events into BLoCs, addressing their inability to handle one-off occurrences like snackbars or redirects, thereby solving a fundamental problem in BLoC’s state management within the Flutter ecosystem.

The past, present, and future of native interop by Daco Harkes and Hossein Yousefi

4:10 PM — Flutter Forest

Discover how JNIgen/FFIgen simplifies the integration of Flutter with native code, thereby improving app performance and facilitating feature development. This presentation highlighted its advantages for plugin development and discussed future plans.

Day 3 — July 5

Hacking and protection of Mobile Apps and backend APIs. Threat modeling exercise by Tomáš Soukal

9:20 — Flutter Forest

The audience was educated on safeguarding mobile apps and APIs against attacks such as botnets and token hijacking, employing strategies rooted in OWASP MAS (Mobile Application Security) practices.

Developer Diary: Journey of a payment integration by Nino Handler

10:15 AM — Flutter Forest

Nino shared insights into their journey of successfully integrating an “unknown” payment provider into an app. He detailed the transition from a high-maintenance, native library approach on Android and iOS to a more sustainable, browser-based payment flow. The presentation covered challenges and solutions associated with WebViews, In-App browsers, Firebase Hosting, and navigation using Deep Links.

Migrating 2+ Million Daily Users to Flutter with 50+ Engineers by Csongor Vogel, Lucas Britto, Bruno Reginato

11:10 AM — Widget Way

Talabat’s migration to Flutter showcased approaches, challenges, and lessons from integrating Flutter into a native Android and iOS setup, emphasizing the importance of a learning culture and quality standards for a huge mobile team.

App Architecture: Faster, Better… Simpler by Kirill Bubochkin

1:25 PM — Async Area

This talk challenges the overcomplication of app architecture by newcomers following popular trends, suggesting a simpler approach and discussing the pitfalls of misapplying principles like SOLID, DRY, and Clean Architecture, with insights on using the DCM feature for code analysis.

Working with forms as an ecosystem by Vasyl Dytsiak

2:20 PM — Async Area

This talk explored the creation of a supportive ecosystem for complex form handling in Flutter, highlighting how specialized form engines like reactive_forms, coupled with supportive packages such as reactive_forms_widgets and reactive_forms_generator, streamlined development, ensured code consistency and saved time. It encouraged open-source contribution and demonstrated the use of these tools for advanced form functionalities.

Speechless Slide Karaoke with Chet Haase

3:00 PM — Stadia Room

Oh, that one was a delightful mix of laughter and fun!

FlutterCon is far more than just talks and workshops!

Beyond these formal events, numerous fun and cool activities were happening. Here, I’m excited to share just a glimpse of the engaging experiences that were part of the conference.

Conclusion

The magnitude and impact of FlutterCon Europe cannot be overstated! This conference goes beyond just presentations; it’s about connecting with great individuals from the community, engaging in insightful discussions, and enjoying fun activities together. I’m thrilled to have had the opportunity to speak at this year’s event and am eagerly anticipating attending the conference again next year.

Fluttercon Europe 2024 was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

When you’re developing a Flutter application that’s intended to be more than just a Proof of Concept (PoC) to be set aside in a few weeks, I recommend opting for a monorepo approach in most scenarios.

Monorepo Advantages

Adopting a monorepo means that your codebase is organized into Flutter/Dart packages rather than mere directories. This setup introduces “physical” boundaries instead of merely “logical” ones.

The advantages of this strategy include:

• Improved Separation of Concerns
  Encapsulation is now enforced by the analyzer/compiler, necessitating the explicit export of types from one package for their use in another. This enhances modularity and clarity in your project structure.
• High Reusability Potential
  It becomes significantly easier to reuse a package in another application within the same repository, or to migrate the package to a different repository. This is particularly beneficial compared to extracting types from a large, monolithic package, especially when those types are tightly coupled with integrated with the rest of the package’s content.
• Optimized Build Times and CI Resources
  To understand how a monorepo can lead to optimizations in terms of time and cost, I recommend reading the Selective CI Checks article. It offers practical solutions for making your Continuous Integration processes more efficient.

A nuance in Dart Analyzer/Compiler

One peculiar aspect of Flutter/Dart monorepos is that the Dart compiler permits cyclic dependencies between packages. This implies that if package A depends on package B, you can also make package B depend on package A. While this might seem like a flexible feature, I view it more as a drawback than a benefit. The presence of cyclic dependencies is often considered a red flag, as it results in tightly coupled code that can become challenging to maintain.

In contrast, compilers for other programming languages, such as C# or Kotlin, will immediately flag cyclic dependencies as errors, preventing their occurrence. This restriction helps ensure a cleaner, more maintainable codebase by encouraging developers to think more carefully about their project’s architecture and dependency structure.

Melos to the Rescue

Fortunately, the Melos tool, which I’ve discussed in my previous articles, not only significantly eases the management of Flutter/Dart monorepos but also comes equipped with a built-in feature to detect cyclic dependencies.

The command to leverage this feature is melos list --cycles.

Running this command produces immediate results without incurring additional resource consumption. This makes it an ideal check to integrate into your project’s CI pipeline, ensuring your codebase remains free from cyclic dependencies without impacting your CI resources.

To illustrate how this works in practice, let’s revisit the application discussed in the Modularized Dependency Injection article, which has the following module structure.

Well Organized Dependencies

When I execute the melos list --cycles command within the repository containing the aforementioned package structure, Melos reports no issues. This outcome is as pleasing to me as it is to Melos!

Cyclic Dependency Example

When I introduce a cyclic dependency by linking the domain package back to the data package, the solution still compiles, and the application runs without any apparent issues. However, this practice is akin to walking on thin ice. It’s a very slippery slope that I strongly advise against.

The melos list --cycles command complains immediately in this case, cool!

Make sure you check this PR to see how it is integrated into the CI flow.

Further Reading

In addition to being mindful of dependencies in a monorepo it is also important to correctly manage the external dependencies of your packages. To gain a deeper understanding there, I highly recommend checking out this dedicated article on the topic.

Useful Links

• https://medium.com/itnext/flutter-modularized-dependency-injection-4362649f84ed
• https://medium.com/itnext/flutter-selective-ci-checks-2d79ffbd26e5
• https://medium.com/itnext/flutter-mind-your-dependencies-52072df6d96

Flutter: Detecting Cyclic Dependencies in a Monorepo was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the large-scale Flutter projects that our team has been working on for the last 4+ years, the topic of Mobile UI Tests Automation has always been on the table. With our first app, we released updates every month, gradually moving to biweekly releases for subsequent apps. The automation of functional application testing, conducted at least on a nightly basis, facilitates faster and more confident application releases. The importance of this is clear to both the team and the business.

Our first Flutter app used Flutter Integration Testing, in combination with Github Actions and Firebase Test Lab. However, our experience with Flutter Integration Testing was not the smoothest. Additionally, its limitations in covering WebViews or Native views could pose significant problems.

Another Flutter team used the first version of Patrol on a different project. In both instances, it was primarily the developers who wrote these tests, but there was a desire among QAs to take ownership.

Our latest Flutter projects had a more complex setup. The teams have been working on a white-label framework, building several Full Flutter applications while also integrating some Flutter features into existing native apps (iOS + Android). These existing native apps already had automation running, so last year we conducted an investigation to identify which automation tool would best suit our needs for the Full Flutter ones.

The Tools We Considered

The table below provides a brief overview of the tools under consideration. Please note that some known limitations of certain tools are not depicted in the table.

What I found really interesting is that Maestro was formerly known as Conductor, and Patrol was previously named Maestro! You can check this rename in the Maestro repo and this one in the Patrol repo.

It’s important to note that black-box testing of Flutter views is conducted based on the provided semantics information. By default, this information is included in widgets that display text. However, you can attach semantics information to any widget using Flutter’s Semantics widget.

Additionally, the long-living accessibility-id issue was finally resolved in Flutter 3.19, thanks to Bartek Pacia! As a result, a new accessibility identifier property of the Semantics widget is now propagated to the native accessibility hierarchy.

What Was Important to Us?

We paid special attention to the following aspects of the tools under consideration:

• Maturity and maintainability
• Black-box testing
• Inspecting tools
• Compatibility with our QAs' skills

Our Choice

Given that WebdriverIO is a mature tool already in use for our native apps and familiar to our QAs, and since it is technically capable of covering both full Flutter and Add-to-app Flutter apps, our decision to broaden its use was straightforward. This choice also amplified our motivation to pay closer attention to the Semantics trees in our apps, as they are not only crucial for impaired individuals, but also serve as a bridge to UI Tests automation tools!

Bonus: A Demo of Maestro’s Ease of Use!

Even though we didn’t choose Maestro for our latest Flutter apps, I was struck by its speed and ease of use.

So, to give you a notion of it, I wiped off the dust from my first Flutter pet project I started 5 years ago and decided to automate a test case. The project is MemMe, a laconic flashcards app designed to make memorization easy.

With just one command, I installed Maestro and began experimenting with Maestro Studio. I wrote the following flow to test the case of adding a new flashcard to the freshly installed application. It was so quick and enjoyable to write that I finished the test before even finishing my cup of tea!

The animation below demonstrates the test flow run. By the way, the video was recorded using the built-in feature in Maestro.

Conclusion

Don’t hesitate to invest time exploring the world of Mobile UI Tests automation. With the right tools and understanding, this investment can significantly enhance your ability to deliver high-quality, reliable applications. It’s an investment that quite often pays off.

Resources

• https://patrol.leancode.co/
• https://fluttium.dev/
• https://maestro.mobile.dev/
• https://appium.io/

Flutter: Choosing Mobile UI Tests Automation Tool was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

Has your Flutter project already reached the stage when Continuous Integration (CI) pipelines require optimization to save both time and money? Well, there are a bunch of approaches for optimization, one of which is selective CI checks.

Since you are looking for ways to optimize your CI, the odds are you have a sizeable project and may already use a Monorepo.

In this article, I showed a clean small monorepo conveying the idea of dealing with Flutter app modularization. I’ll use the same repository here to share a way to implement selective CI checks.

Full CI Checks Setup

First, let’s implement some basic CI checks.

For the Counter App in my repository, which consists of 5 modules and uses Melos to manage the monorepo, I used the following CI checks in the basic Github Workflow.

Each of the CI steps outlined in the above workflow executes for each of the five modules in the monorepo. This isn’t the most efficient use of resources as not every pull request involves changes to all the modules. Therefore, there’s space for improvement!

Selective CI Checks Setup

The concept behind selective CI checks is to only validate the segments of code that are relevant or impacted by a specific change, such as a pull request. Methods like git diff or path filters can be employed.

For Flutter Monorepos that use Melos, the Melos Diff Filter is a handy tool, especially when combined with IncludeDependends Filter. Utilizing the command melos list --diff=origin/main..HEAD --include-dependends, we can obtain a list of packages that have changed compared to the main branch, as well as their dependents. Afterward, we can set the filter list into melos_packages variable which will act as a global scope for all the melos commands. Here comes the corresponding workflow.

Selective CI Checks In Action

For the sake of the example I opened a tiny PR with a change in data module to show that the Selective CI checks will run only on it and on app module because it depends on data.

The following screenshot illustrates the significant difference in resource allocation, which is quite noticeable even for such a small repository. Just think of the substantial improvement potentially achievable on a production project with hundreds, or even thousands, of tests and other CI checks!

Conclusion

Verifying everything with every code change is inefficient, particularly for large projects. The act of optimizing is a delicate balance of efficiency, cost, and performance. By implementing the right strategy, you can achieve significant improvements in your CI pipelines.

Useful Links

• https://github.com/Pavel-Sulimau/flutter_modularized_di
• https://github.com/Pavel-Sulimau/flutter_modularized_di/blob/a65af8b2657fbdb5607f40bbc2225af0f8890dbd/.github/workflows/ci.yaml#L42C3-L42C15

Flutter: Selective CI Checks was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

It’s been over 5 years since Flutter released its 1.0 version in December 2018. Today, Flutter officially supports 6 platforms:

• Mobile: iOS and Android
• Desktop: Windows, MacOS, Linux
• Web

In this post, I’d like to compare the popularity of Flutter with other cross-platform mobile development technologies.

Google Trends: Interest over time

Numbers represent search interest relative to the highest point on the chart for the given region and time. A value of 100 is the peak popularity for the term. A value of 50 means that the term is half as popular. A score of 0 means that there was not enough data for this term.

I began by comparing the interest in Flutter with that of React Native, Xamarin, .NET MAUI (which is the successor of Xamarin), and Ionic using Google Trends for the last 10 years.

This is the query link for the chart you can see in the picture below. The tool allows us to compare only 5 terms, so I didn’t include Apache Cordova, which is even less popular than Ionic. Also, I didn’t include Compose Multiplatform the data for which will not even reach the value of 1 in this popularity chart.

Stack Overflow Trends: Asked Questions

Let’s also take a look at the number of questions asked on Stack Overflow with the help of Stack Overflow Trends. This is the query link for the chart below.

It tracks interest in programming languages and technologies based on the number of Stack Overflow questions asked per month.

Leaders: Flutter vs React Native

The charts above paint a vivid picture, clearly demonstrating that Flutter and React Native have been significantly more popular in recent years compared to their competitors.
In the table below, you can find additional numbers found on GitHub and other relevant platforms as of today.
The latest stable versions are Flutter 3.19.3 and React Native 0.73.6.

Sources

• https://trends.google.com/trends/explore?cat=31&date=2016-03-17%202024-03-17&q=Flutter,React%20Native,Xamarin,MAUI,Ionic
• https://insights.stackoverflow.com/trends?tags=flutter%2Creact-native%2Cxamarin%2Cmaui%2Cionic-framework%2Ccordova
• https://flutter.dev/
• https://reactnative.dev/
• https://github.com/flutter/flutter
• https://github.com/facebook/react-native
• https://dotnet.microsoft.com/en-us/apps/xamarin
• https://dotnet.microsoft.com/en-us/apps/maui
• https://ionicframework.com/
• https://cordova.apache.org/
• https://www.jetbrains.com/lp/compose-multiplatform/

Modularization? Why?

Let’s say you’re already at the stage when the maintainability of your Flutter project is an important aspect for you, so you want to ensure you’re adhering to the best guidelines to achieve suitable architecture and code quality and keep it at the desired level.
So in that case separation of concerns, encapsulation, coupling, and cohesion are the things that you would like to govern in your chosen architecture.
It’s preferable to use physical separation over logical, i.e. divide your project into Dart/Flutter packages instead of merely grouping stuff into different directories. If you already have a not-tiny Flutter app with just logical separation, I bet you’ll likely fail to refactor it into physical packages that will mirror the directory structure you already have. This challenge often arises because it’s easy to breach or overlook architectural constraints when there is no physical separation.

Dependency Injection in modules? How?

It stands to reason that the exact architecture depends on your project, team, knowledge, etc. I’ve got no intention to discuss architectures in the scope of this article, but rather want to concentrate on how you can organize Dependency Injection (DI) in a modularized Flutter app.

Refactoring The CounterApp

To convey the concept, let’s take the Counter Flutter App and modify it by introducing some basic packages. The diagram below depicts the packages I’ve selected and how they depend on each other.

Cross-Cutting Concerns

A cross-cutting concerns package typically contains things that affect the entire application and can be used by all the layers. I put DI abstractions into it.

The first one is called DI and this interface is responsible for obtaining objects from a DI container.

The second interface is called DIRegistrar, it provides the API to register dependencies in a DI Container. This interface must be exposed only to its actual implementation and to the ModuleDependencies abstraction and implementations.

The third part of the puzzle is ModuleDependencies. It must be implemented by all the modules that have dependencies.

DI Abstractions Usage

The modules are supposed to encapsulate the implementation details and expose only what is necessary.

For example, the fact that I added flutter_bloc state management in the presentation package is an implementation detail, so it can be easily replaced just inside this package without the need to modify the other packages at all.

In the data package I decided to use shared_preferences to keep the state of the counter between the application launches. Again, this is “known” only to the data package itself.

The app, of course, will have the transitive dependencies on shared_preferences and flutter_bloc in the end, as this is inevitable and intended for the root package that eventually bundles everything together in an artifact, e.g. ipa, apk.

At the initialization phase of the application, we simply go through all the configured modules and tell them to register their dependencies.

You might’ve noticed the GetItDI class in the piece of code above. This is the implementation of DIRegistrar that I put in the app package. This implementation uses the get_it package. Again, should you want to switch to another DI Container, you’ll be able to do that as easily as just changing the implementation of DIRegistrar in the app layer without affecting all the other packages in any way.

Hopefully, the concept is clear to you by now, but you’re more than welcome to explore the repository to inspect the remaining bits!

Conclusion

By dividing your project into physical modules, you immediately benefit from the compiler and static analysis working in your favor. This makes it significantly more difficult to overlook any architectural violations as they arise. The overhead of managing a Monorepo is minor compared to the numerous benefits it offers. Additionally, it’s important to become familiar with the Melos tool, as it greatly simplifies Monorepo management in the Flutter and Dart ecosystem.

Resources

GitHub - Pavel-Sulimau/flutter_modularized_di: Modularized Flutter Counter App Honoring Clean Architecture Principles and Using Simple DI Abstractions to Preserve Encapsulation within Modules.

Flutter: Modularized Dependency Injection was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

I believe many Dart & Flutter monorepo projects are already using Melos. It’s a useful tool for managing multiple packages, and I’m glad to see it continually improving.

Shared Dependencies Feature

In this article, I am eager to shine a spotlight on the Shared Dependencies feature that was introduced in Melos 3.2.0.

Essentially, if you want to share a dependency version between the packages in your monorepo, just add the dependency to the melos.yaml file, and melos bootstrap command will make sure your pubscpec.yamlfiles are updated accordingly to match the version defined in the melos.yaml file. It works not only for dependencies or dev_dependencies but for environment configuration as well.

More context about it can be gained from its feature request and the PR where it was implemented.

Shared Dependencies In Practice

Let’s see how it works in practice using the Flame project as an example.
At the moment of writing a bunch of packages from the Flame monorepo depend on meta v1.9.1, you can see the copied bootstrap configuration below.

After I update the meta version to meta: ^1.10.0 in the melos.yaml and run the melos bs command, I get 49 packages bootstrapped, 9 of them that depend on meta got the very same update right away! That’s quite handy and may ease the dependencies management in Dart/Flutter monorepos.

Conclusion

While it’s true that package management in the Dart/Flutter ecosystem is less mature compared to other platforms like .NET, we are fortunate to have tools like Melos at our disposal that can simplify the process. By actively contributing to such tools, we can play a role in improving the developer experience and fostering greater satisfaction within the community.

Resources

• https://melos.invertase.dev/commands/bootstrap#shared-dependencies
• https://pub.dev/packages/melos/changelog#320
• https://github.com/invertase/melos/issues/94
• https://github.com/invertase/melos/pull/526
• https://github.com/flame-engine/flame/blob/78380b9d3bb895e20f382c4a1227bcc11e5038b9/melos.yaml#L16C1-L25C16

Flutter: Sharing Dependencies in a Flutter Monorepo was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

When you work on a Flutter/Dart project where code coverage is measured or even enforced, then you will likely want to have a setup that will help you see the picture locally.

One way is to run tests collecting the coverage with a terminal command or some script, i.e. flutter test --coverage, see more info on Flutter CLI here.

However, if you primarily use VS Code, then you can utilize a more convenient launch configuration to be able to run your tests and generate the coverage right from the tests themselves. More specifically, we would need to use a custom codelens configuration.

‘Coverage’ codelens launch configuration in VS Code

As soon as the following configuration is added to the launch.json file, a new button will be made available to allow us to run the tests.

After executing the ‘Coverage’ command on a test(s), you will notice the lcov.info file appearing in the coverage directory.

Be aware of this issue if you’re trying to make it work on a plain Dart (non-Flutter) package.

VS Code Extensions for Code Coverage

While various tools exist that can generate HTML reports based on coverage files, analyzing coverage directly in VS Code can be accomplished using the following two extensions:

1. Flutter Coverage
   This extension adds a tree view to the test view container. It shows the coverage per file/folder.
2. Coverage Gutters
   Displays which lines of a file are covered and which are not.

Conclusion

For VS Code users, custom codelens configurations and specific extensions can provide coverage analysis directly within the editor, simplifying the process significantly.

Resources

• https://dartcode.org/docs/launch-configuration/
• https://dartcode.org/docs/custom-codelens/
• https://marketplace.visualstudio.com/items?itemName=Flutterando.flutter-coverage
• https://marketplace.visualstudio.com/items?itemName=ryanluker.vscode-coverage-gutters
• https://github.com/dart-lang/test/issues/1265#issuecomment-644995230

Flutter: Code Coverage tools in VS Code was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

What is OpenAPI?

The OpenAPI Specification (OAS) provides a formal standard for describing HTTP APIs.

It is a specification language for HTTP APIs that defines structure and syntax, typically written in YAML or JSON.

It was originally based on the Swagger 2.0 Specification, donated by SmartBear Software in 2015. Currently, the OAS is maintained, evolved and promoted by the OpenAPI Initiative (OAI), a consortium of industry experts with an open governance structure under the Linux Foundation umbrella.

OpenAPI Specification enables you to describe your APIs in language-agnostic terms, effectively separating them from dependencies on any particular programming language. This approach not only facilitates a clearer understanding of how an API functions but also streamlines processes such as generating client code, crafting tests, enforcing design standards, and much more.

This description, which may be stored as one or more documents (such as local files or HTTP-accessible network resources), is called an OpenAPI Description (OAD).

Below, you can see an example of OpenAPI Description. This sample illustrates how OAD conveys essential details about an API, including its endpoints, supported operations, and data structures, in a structured and easily understandable format.

What are the Swagger Tools?

Swagger Editor
This is an intuitive API editor that assists in designing and documenting APIs using the OpenAPI Specification. It offers real-time feedback and syntax checking to streamline the API design process.

Swagger UI
This tool visualizes OpenAPI Specification definitions in an interactive interface. It allows users to explore and interact with the API’s endpoints, providing a clear and user-friendly presentation of the API’s capabilities.

Swagger Codegen
It generates server stubs and client SDKs directly from OpenAPI Specification definitions. This automation significantly reduces the manual coding effort, ensuring a seamless and efficient API implementation.

Swagger Codegen in Dart/Flutter

I can’t stress enough the advantages you get by using the Swagger Codegen packages. Those tools have saved huge amounts of resources and quite some headaches on many projects for me. There are plenty of them for various libraries and programming languages.

In the Flutter/Dart world I’ve been using the swagger_dart_code_generator package since 2020 on projects of various sizes and it has proved itself as quite a reliable one.

Enforcing Consistency and Standards in OAD files

Luckily, code formatters, code linters, static code analyzers, various types of tests, and code reviews became industry standards in Continuous Integration software development practice.

That’s awesome that there are open-source tools available that can bring more consistency and better standards to the OpenAPI definitions a back-end API provides.

If your back-end teams do not use any tools in their CI to check the quality of the OAD files, it’s a good idea to start doing so. Give a read to the best practices on learn.openapis.org.

Keep a Single Source of Truth

OADs should be committed to source control, and, in fact, they should be among the first files to be committed. Information should not be duplicated in different places, so keeping a single source of truth is always a nice idea.

Enforce formatting

The same formatting style enforced for all team members is never a bad idea, especially with huge JSON/YAML files that OAD can become. Tools like EditorConfig are great for keeping coding styles consistent across different editors and IDEs. Additionally, a tool like Prettier can be integrated into your CI pipeline to automatically ensure that everyone sticks to the agreed-upon formatting rules.

Keep the quality bar with an OAD Linter

Spectral is a powerful open-source tool that’s helpful for working with JSON or YAML data, specially designed for OpenAPI, AsyncAPI, and JSON Schema.

Spectral comes with several features right out of the box:

• Custom Rulesets: You can create your own rules to lint JSON or YAML objects, tailoring checks to your specific needs.
• Ready-to-use Rulesets: Spectral has built-in rulesets for validating and linting OpenAPI v2 & v3.x and AsyncAPI Documents.
• API Style Guides: Automated API Style Guides using rulesets improve consistency across all your APIs.
• Built-in Functions: A variety of pre-made functions are available for creating custom rules. These include checks for patterns, parameters, alphabetical ordering, character limits, and verifying the presence of specific keys in an object.
• Custom Functions: Create custom functions for advanced use cases.

For the example’s sake, I used a Weather OAD I found at APIs Guru. Here is the OAD 3.0.1 file in yaml format.

Below you can see just a few rules added to the Spectral config file.

When Spectral linter scans the poorly described OAD from VisualCrossing it immediately gives quite useful feedback, see the screenshots below. It’s worth noting that the effectiveness of Spectral increases with the number of rules configured. More rules mean more comprehensive checks, leading to higher quality and more reliable API descriptions in the long run.

Validating Back-End Responses against OAD/JSON Schema

JSON Schema is a specification for defining the structure of JSON data i.e. JSON request body and response in case of APIs. Basically, JSON schema defines various keys and their values and certain constraints on the values.

OpenAPI Specification 3.1 (released in February 2021) supports 100% compatibility with the latest draft (2020–12) of JSON Schema.

This means that JSON Schema validation tools like Ajv can be used to ensure that the actual responses from your back-end endpoints are compliant with what is defined in OpenAPI Description of the backend. Ajv can be used in the scope of integration tests or in PostMan tests.

Conclusion

The abundance of valuable open-source tools available for enhancing and maintaining the quality of back-end endpoints and their contracts is a significant asset. Given their benefits, it’s hard to justify not using these tools in any serious project. Avoiding them out of laziness or reluctance to invest time in the initial setup shouldn’t be an excuse.

Feel free to check out the demo repository with the stuff mentioned above and bring value to your projects.

Resources

• https://www.openapis.org
• https://swagger.io
• https://pub.dev/packages/swagger_dart_code_generator
• https://github.com/Pavel-Sulimau/open_api_playground
• https://json-schema.org
• https://ajv.js.org
• https://www.sergigisbert.com/blog/validating-api-requests-and-json-schemas-with-postman
• https://learning.postman.com/docs/api-governance/configurable-rules/spectral

OpenAPI Excellence: Maximising Quality with Automation Tools was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.