38 Dart & Flutter Tips That Actually Make a Difference in Production

mt-laid — Sat, 26 Sep 2026 13:29:36 +0000

After 4+ years of building Flutter applications, I’ve learned that the biggest improvements often come from small decisions repeated every day.

A better way to handle a nullable value. A cleaner approach to lists. Knowing when compute() actually makes sense. Catching memory leaks instead of guessing about them. Keeping business logic where it belongs and mutch more.

I collected these lessons from code reviews, production bugs, experiments, reading lots of articles & other devs code and things I’ve learned the hard way.

This isn’t another list of generic “Flutter best practices.” For each tip, I’ll focus on what it does, why it matters, and when you should actually use it.

Part 1: Modern Dart Language Features

1. Stop reaching for `!` after a null check

// Before
if (userData != null) {
  sendEvent(userData!.name);
}

// After
if (userData case final user?) {
  sendEvent(user.name);
}

The real problem with != null checks is that they're a snapshot in time, nothing more. If userData is a class field rather than a local variable, the analyzer can't guarantee its value hasn't changed between the check and the use — especially across an async gap or with a computed getter. We hit a real production crash after a "harmless" refactor turned a final field into a computed getter and silently broke that assumption. Pattern matching ties the check and the binding into a single step, so this class of bug simply can't happen.

2. Build your lists declaratively

final output = [
  welcomeMessage,
  ?optionalMessage,
  if (encrypt)
    ...messages.map(encrypt)
  else
    ...messages,
];

Instead of chained .add() and .addAll() calls. The real payoff shows up in code review: the entire structure of the list is visible in one expression, instead of a reviewer having to trace mutations across six imperative lines.

3. Use `switch` with pattern matching instead of nested `if/else`

return switch (user) {
  Admin() => AdminPage(),
  User(verified: true) => HomePage(),
  _ => WelcomePage(),
};

The real value here is exhaustiveness checking. When you add a new case months later — a new enum value, a new subtype — the compiler forces you to handle it immediately, instead of finding out from a support ticket that someone hit the unhandled path in production.

4. Use destructuring to unpack values in one step

final Point(:x, :y) = point;
final (x, y) = coordinates;
final [x, y, ...] = pointList;

Especially useful with records when handling composite data coming back from an API — it saves time and eliminates the ordering mistakes that happen when you unpack values manually, one variable at a time.

5. `async/await` aren't always necessary

// Before
Future<User> getUser() async {
  return await repo.getUserDetails();
}

// After
Future<User> getUser() => repo.getUserDetails();

The rule: only drop them if the function isn't doing any real work with the result. If you need try/catch or need to transform the result, keep them — removing them in that case costs you the ability to catch errors locally.

6. Explain why you're ignoring a lint warning

// This color is intentionally static and doesn't follow the theme
// ignore: use_design_system_colors
color: Colors.black

With 4 developers on my team, this one small rule has saved a lot of repeated back-and-forth in review. An ignore with no explanation just means a different reviewer asks the same question next time.

Part 2: Testing You Can Actually Trust

7. Write assertions that read like a sentence

expect(list, isEmpty);
expect(result, isA<MyClass>());
expect(() => run(), throwsA(isA<MyException>()));

The difference between a clear matcher and a vague assertion shows up months later, when a test fails and you've long forgotten the context: one minute to understand what broke, versus ten minutes of investigation.

8. Don't drag unnecessary dependencies into your tests

// Avoid
pumpWidget(AppScaffold(body: AppText('Hi')));

// Prefer
pumpWidget(AppScaffold(body: Text('Hi')));

If your custom widget (AppText, say) silently swallows errors, a test can pass even when the real logic underneath is broken. We fell into this trap for real — and it cost us time tracking down a "passing test for code that didn't work."

9. Golden tests for catching visual regressions

Golden tests (matchesGoldenFile) capture a reference image of a widget and diff it against a fresh render on every CI run. The payoff: you catch a visual regression — shifted padding, a color that changed by accident — before it ever reaches human review, let alone production. The cost: you need to pin them down carefully, because font rendering differences across CI environments produce false positives. We only run them inside one standardized CI image to avoid that.

10. Use `mocktail` over `mockito` for new projects, and `fake_async` for time-dependent tests

mocktail skips code generation entirely, which saves real build time on larger projects. fake_async lets you test code involving Future.delayed or Timer without actually waiting in real time — faster, deterministic tests, instead of a real await Future.delayed() that slows down CI and occasionally produces flaky results.

Part 3: Debugging & Naming

11. Let your logger do its job

// Before
logger.warning('$error $stackTrace');

// After
logger.warning('message', error, stackTrace);

The difference shows up in tools like Sentry: a properly structured stack trace lets these tools group similar errors automatically, instead of leaving you to search through a wall of text buried in one message.

12. Name Sliver widgets clearly

// Confusing — silently returns a Sliver
class DashboardAppBar extends StatelessWidget { ... }

// Clear
class SliverDashboardAppBar extends StatelessWidget { ... }

The analyzer won't warn you about this one — you only find out at runtime, usually with a red screen far away from where the widget was actually defined. Clear naming here is real protection, not just tidiness.

13. Use dedicated widgets instead of single-purpose `Container`s

Container is incredibly flexible, which is exactly why it's easy to reach for it even when you only need one simple behavior.

For a single responsibility, prefer the widget that communicates that responsibility directly:

// Instead of
Container(
  padding: const EdgeInsets.all(24),
  child: child,
);

// Prefer
Padding(
  padding: const EdgeInsets.all(24),
  child: child,
);

The same idea applies to common cases:

ColoredBox(color: Colors.white, child: child);
DecoratedBox(decoration: decoration, child: child);
Center(child: child);
SizedBox(width: 100, height: 100, child: child);

The benefit isn't just a smaller widget. The code tells the reader exactly what it is doing.

Don't take this too far, though. When you're combining several responsibilities, Container can be clearer:

Container(
  color: Colors.white,
  padding: const EdgeInsets.all(16),
  child: child,
);

Use the dedicated widget when it makes the intent clearer; use Container when its flexibility genuinely helps.

14. Use dot shorthand when the type is already obvious

Modern Dart can remove repetitive type names when the surrounding context already tells the compiler what type is expected.

Instead of:

padding: const EdgeInsets.all(16),
mainAxisSize: MainAxisSize.min,
brightness: Brightness.dark,

you can write:

padding: const .all(16),
mainAxisSize: .min,
brightness: .dark,

This is particularly useful in Flutter widget trees and switch expressions, where the expected type is already clear.

It's a small readability improvement, but it reduces visual noise without changing the behavior of the code.

Part 4: Performance — Beyond the Basics

15. Stop worrying about shader jank — but know why

If you've been carrying around --cache-sksl shader warm-up routines from an older project, you can retire them. Impeller — Flutter's rewritten rendering engine — compiles shaders ahead-of-time at build time instead of the first time they're used at runtime, which is what caused that old "stutters once, then runs smooth forever" bug. Impeller is now the default rendering engine across the current stable line: default on iOS since Flutter 3.16, and on Android since Flutter 3.22. If you're still hand-rolling shader warm-up code, it's dead weight. The advanced move here isn't a hack — it's knowing the old hack is obsolete and trusting the default.

16. Use long-lived isolates for repeated work, not `compute()` in a loop

compute() (built on Isolate.run) is convenient, but it spins up and tears down a fresh isolate every single call — if you're doing the same kind of computation repeatedly, that spawn-and-copy overhead adds up, and you'll get better throughput from an isolate that stays alive and receives multiple messages over time via SendPort/ReceivePort. This is the pattern usually called a "background worker" isolate. Reach for it when you're processing a stream of items (image thumbnails, incoming socket messages) rather than one one-off blob of JSON.

// One-off: fine
final result = await compute(parseJson, jsonString);

// Repeated: spin up once, reuse
final worker = await Worker.spawn(); // keeps a SendPort/ReceivePort alive
for (final item in incomingStream) {
  worker.send(item);
}

If an isolate is finishing with a large object to hand back (a decoded image buffer, say), use Isolate.exit() instead of a normal return — it transfers ownership of the object to the receiving isolate instead of copying it, which matters a lot for large payloads.

17. Reach for a custom `RenderObject` only when layout widgets genuinely can't do it

This is a legitimate escape hatch, not a toy. The honest criteria: you need it when existing layout widgets like Row, Column, Stack, or Wrap can't express the layout you need, when you need fully custom painting like a chart or a game element, when you need custom hit-testing logic, or when you need to skip the Widget/Element overhead entirely for performance-critical rendering. If none of those apply, you don't need it — CustomPaint combined with a CustomMultiChildLayout covers most "custom layout" needs without touching the rendering pipeline directly.

18. `--obfuscate --split-debug-info` — and actually keep the output

This one's less about runtime performance and more about a production hack almost nobody sets up correctly on the first try:

flutter build appbundle --obfuscate --split-debug-info=./debug-info/1.4.2

This strips Dart symbol names from the release binary while keeping a private mapping file for symbolication. The part people miss: you need that split-debug-info output to de-obfuscate stack traces from real crash reports — if you don't archive that folder per release version, every Crashlytics or Sentry stack trace you get from that build is permanently unreadable gibberish. Tag the folder with the exact version/build number and store it somewhere durable. One caveat worth knowing: obfuscation doesn't encrypt string literals — API keys hardcoded in Dart are still fully readable in the binary, so this isn't a substitute for actually not shipping secrets in source.

19. Prove memory leaks instead of guessing at them

"Did I actually leak that controller?" is usually answered by intuition. WeakReference and Finalizer let you answer it with evidence: attach a Finalizer to an object, and it fires a callback when the GC actually collects it — if the callback never fires after you navigate away and force a GC, you have a confirmed leak, not a suspicion.

final _finalizer = Finalizer<String>((label) {
  debugPrint('Collected: $label');
});

class MyController {
  MyController() {
    _finalizer.attach(this, runtimeType.toString(), detach: this);
  }
}

This is dev/debug-only tooling — not something you ship — but it turns "I think this page leaks" into "I proved this page leaks, and here's the exact class."

20. Keep heavy computations out of `build()`

build() is not a one-time setup method. Flutter can call it many times, so putting expensive work inside it means you may repeat that work on every rebuild.

// Avoid
@override
Widget build(BuildContext context) {
  final data = expensiveOperation(widget.inputData);
  return DataChart(data: data);
}

Move work that doesn't need to happen during rendering to the appropriate lifecycle method or state-management layer:

@override
void initState() {
  super.initState();
  processedData = expensiveOperation(widget.inputData);
}

@override
void didUpdateWidget(MyWidget oldWidget) {
  super.didUpdateWidget(oldWidget);

  if (widget.inputData != oldWidget.inputData) {
    processedData = expensiveOperation(widget.inputData);
  }
}

@override
Widget build(BuildContext context) {
  return DataChart(data: processedData);
}

The important distinction is that build() should primarily describe the UI. If something is expensive and doesn't need to happen for every render, don't make the rendering pipeline pay for it.

21. Use `compute()` for genuinely intensive work

Moving work out of build() isn't always enough. Large JSON parsing, expensive transformations, or other CPU-heavy operations can still block the main isolate if you execute them synchronously.

For genuinely expensive one-off work, compute() is a convenient escape hatch:

int calculateFibonacci(int n) {
  if (n <= 1) return n;
  return calculateFibonacci(n - 1) + calculateFibonacci(n - 2);
}

final result = await compute(calculateFibonacci, 50);

Don't reach for it automatically, though. Data passed between isolates has a transfer cost. For small operations, that overhead can be greater than the work itself.

For repeated workloads, the long-lived worker-isolate approach from #14 can be a better fit.

22. Don't turn simple conditions into nested ternaries

Ternaries are great when the condition is simple:

final title = isLoading ? 'Loading...' : 'Ready';

But once you start nesting them, readability falls quickly:

// Hard to scan
return isBlocked
    ? BlockedWidget()
    : status == .pending
        ? LoadingWidget()
        : status == .success
            ? SuccessWidget()
            : ErrorWidget();

Prefer a normal if or a switch expression when the decision has multiple branches:

if (isBlocked) {
  return BlockedWidget();
}

return switch (status) {
  .pending => LoadingWidget(),
  .success => SuccessWidget(),
  _ => ErrorWidget(),
};

A shorter expression isn't automatically better code. Once the syntax starts hiding the decision you're trying to express, make the branching explicit.

23. Prefer widget classes over widget-returning methods

A helper method that returns a widget is convenient:

Widget buildHeader() => Padding(
  padding: const EdgeInsets.all(16),
  child: Text('Hello world!'),
);

But that subtree remains part of the parent's build() method. Extracting it into a widget gives Flutter a clearer boundary and gives the component its own public interface:

class Header extends StatelessWidget {
  const Header({super.key});

  @override
  Widget build(BuildContext context) {
    return Padding(
      padding: const EdgeInsets.all(16),
      child: Text('Hello world!'),
    );
  }
}

This becomes especially useful when the subtree is reusable, independently testable, or has its own state and dependencies.

Don't extract every three-line widget just for the sake of it. The point is to create meaningful widget boundaries, not to maximize the number of files in the project.

24. A small `let()` extension can simplify transformations

When a value needs a small transformation, especially a nullable one, a let() extension can keep the operation close to the value:

extension Let<T extends Object> on T {
  R let<R>(R Function(T) transform) => transform(this);
}

For example:

final result = api.getAmountFor(id)
    ?.let(AppFormatters.currency)
    .toUpperCase()
    .let(PaymentLog.new);

This can be useful when you have a sequence of transformations and want to avoid temporary variables.

But this is a style tool, not a rule. If a let() chain becomes harder to read than a few ordinary statements, use the ordinary statements.

25. Let static analysis catch problems before code review

A good analysis_options.yaml setup can catch style problems, common mistakes, API misuse, and other issues while you're still writing the code.

include: package:flutter_lints/flutter.yaml

analyzer:
  errors:
    unnecessary_cast: error
    dead_code: error

The exact lint set depends on the project, but the principle is simple: automate things that don't need human judgment.

For teams, this becomes even more valuable when CI fails on analyzer warnings or lint violations. Code review can then focus more on architecture, behavior, and design decisions instead of repeatedly discussing formatting or mechanical issues.

26. Use spread operators when composing lists

Dart's spread syntax is especially useful when a list is made from several optional or conditional pieces.

Instead of constructing temporary lists:

final headers = defaultHeaders +
    [AppHttpHeader.userId(userId)] +
    (optionalHeaders ?? []) +
    (productId != null ? [AppHttpHeader.productId(productId)] : []);

Compose the structure directly:

final headers = [
  ...defaultHeaders,
  AppHttpHeader.userId(userId),
  ...?optionalHeaders,
  if (productId != null)
    AppHttpHeader.productId(productId),
];

This is related to declarative collection literals from #2, but the useful distinction is list composition: ...? lets you include an entire nullable collection without creating an empty-list fallback.

The main benefit isn't micro-optimizing allocations. It's making the final structure obvious at a glance.

27. Give meaningful numbers a name

A number can be perfectly valid and still communicate almost nothing:

final maxLines = scaleFactor > 1.4 ? 1 : 3;

What does 1.4 represent? Why 1 and 3?

Give values with domain meaning a name:

static const _accessibilityScaleThreshold = 1.4;
static const _largeScaleMaxLines = 1;
static const _defaultMaxLines = 3;

final maxLines = scaleFactor > _accessibilityScaleThreshold
    ? _largeScaleMaxLines
    : _defaultMaxLines;

Now the decision is part of the code itself.

Not every number needs a constant. padding: 16 doesn't necessarily need paddingValue. Name values when the number carries business, design, accessibility, or behavioral meaning.

28. Use `castOrNull` only when invalid data should behave like missing data

When dealing with dynamic data, a direct cast can throw:

final count = data['count'] as int?;

A small helper can make a failed cast return null:

extension CastOrNull on dynamic {
  T? castOrNull<T>() => this is T ? this as T : null;
}

final count = data['count'].castOrNull<int>();

This is useful when malformed data and absent data genuinely follow the same fallback path.

Don't use it as a blanket replacement for validation. If a malformed API response is a real error in your domain, silently converting it to null can hide the problem.

29. Use extension types to give dynamic data a domain-specific API

You already saw extension types in #19 for zero-cost domain types. They can also be useful when you want to put a typed interface around an existing representation without allocating a wrapper object.

For example:

extension type Message(Map<String, dynamic> _payload) {
  String get sender => _payload['sender'] as String;
  String get text => _payload['text'] as String;
  int get timestamp => _payload['timestamp'] as int;
}

final message = Message(payload);

print(message.text);

This can make raw JSON-like data easier to work with while keeping the underlying representation unchanged.

The important limitation is that extension types don't create a runtime wrapper with independent state. Their value is the compile-time API and type safety, not runtime encapsulation.

30. Let `build_runner` watch generated code

If your project uses code generation with tools such as freezed or json_serializable, manually rebuilding generated files after every change gets annoying quickly.

Instead of repeatedly running:

dart run build_runner build

you can use:

dart run build_runner watch

Now build_runner watches the filesystem and regenerates the relevant files as you work.

The main benefit isn't necessarily raw generation speed. It's removing the repeated context switch between editing code and manually starting the generator.

31. Use hooks when lifecycle boilerplate becomes repetitive

For stateful widget concerns such as TextEditingController, AnimationController, or listeners, Flutter hooks can keep setup and cleanup closer together.

For example:

@override
Widget build(BuildContext context) {
  final searchController = useTextEditingController();

  useEffect(() {
    void listener() {
      // React to changes.
    }

    searchController.addListener(listener);
    return () => searchController.removeListener(listener);
  }, [searchController]);

  return TextField(
    controller: searchController,
  );
}

The hook owns the lifecycle of the controller, while useEffect keeps the subscription and cleanup together.

Hooks aren't automatically better than StatefulWidget. If a widget ends up with many unrelated effects, the code can become just as difficult to reason about as lifecycle methods. Keep hooks focused on one responsibility and extract reusable behavior into named custom hooks when appropriate.

Part 6: Dart Language — Genuinely Advanced Features

32. Sealed classes for state that can't be invalid by construction

sealed class AuthState {}
class Loading extends AuthState {}
class Authenticated extends AuthState { final User user; Authenticated(this.user); }
class Error extends AuthState { final String message; Error(this.message); }

return switch (state) {
  Loading() => const CircularProgressIndicator(),
  Authenticated(:final user) => HomePage(user: user),
  Error(:final message) => ErrorView(message: message),
};

The point isn't the switch — it's that bool isLoading + bool hasError + User? user as separate fields allows logically impossible combinations (isLoading == true and hasError == true). Sealed classes make the invalid states unrepresentable, and the compiler's exhaustiveness check means a new state can't silently go unhandled somewhere.

33. Extension types for zero-cost domain types

extension type UserId(String value) {
  bool get isValid => value.length == 24;
}

void fetchUser(UserId id) { ... }

The bug this prevents: passing a raw String meant as a userId into a function expecting a productId — the compiler stays silent because both are just String. extension type gives you a distinct compile-time type that's impossible to mix up, with genuinely zero runtime cost — it's identical to the underlying String in memory, unlike a wrapper class, which needs its own allocation.

34. Deferred imports for real code-splitting

import 'package:my_app/heavy_feature.dart' deferred as heavy;

Future<void> openHeavyFeature() async {
  await heavy.loadLibrary();
  heavy.launch();
}

Most Flutter devs never touch this because most apps don't need it — but if you've got a rarely-used, code-heavy feature (a PDF editor, an in-app video processor), deferred imports keep it out of the initial bundle entirely and only load it when actually invoked. This changes your app's cold-start size, not just a single frame's render time.

Part 7: A Few Extra Useful Tips

35. Tag every hardcoded string so localization never loses one

Every multi-language app hits this: someone hardcodes a string during development ("just temporary"), it ships, and six months later nobody remembers it was never wired into the localization files. I solved this with a tiny extension:

extension StringExtension on String? {
  bool isNullOrEmpty() => this == null || this == "";
  String get hardcoded => this ?? "";
}

Instead of writing Text("Loading..."), I write Text("Loading...".hardcoded). Functionally it does nothing — it just returns the same string. But it means every intentionally-hardcoded string in the codebase is tagged with a unique, greppable marker. When it's time to localize a new batch of strings, I just search the whole project for .hardcoded and get a complete, accurate list of every string that still needs to move into the localization files — no missed strings, no relying on memory or a design doc that's gone stale.

36. Put `BuildContext` lookups behind extensions

Theme.of(context).textTheme, Theme.of(context).colorScheme, AppLocalizations.of(context) — every Flutter codebase ends up typing these dozens of times per screen. I wrap them in extensions on BuildContext instead:

extension ThemeExtension on BuildContext {
  ThemeData get theme => Theme.of(this);
  TextTheme get textTheme => theme.textTheme;
  ColorScheme get colorScheme => theme.colorScheme;
  AppDimensionsTheme get dimensionsTheme =>
      theme.extension<AppDimensionsTheme>()!;
}

extension AppLocalizationsExtension on BuildContext {
  AppLocalizations get l10n => AppLocalizations.of(this);
}

So Theme.of(context).colorScheme.primary becomes context.colorScheme.primary, and AppLocalizations.of(context).welcomeMessage becomes context.l10n.welcomeMessage. It's a small thing, but it compounds: less visual noise in every build method, one place to change if a lookup's signature ever changes, and it reads closer to how the rest of your app's context-based APIs (context.push, context.read, if you're using go_router or Riverpod) already feel — so it doesn't stick out as a one-off convention.

37. Strict `analysis_options.yaml`, with CI failing on any warning

We set this up on the team from day one: any lint warning fails CI, not just errors. The result: code review conversations shifted from repetitive style nitpicks to actual logic and design discussion.

38. Keep business logic completely separate from widgets

When your repository/usecase layer is fully decoupled from widgets, you test it with plain unit tests — no WidgetTester needed. That's dozens of times faster than widget tests. On our team, this separation cut a significant chunk of our CI test suite runtime from minutes down to seconds.

The Takeaway

38 tips, but there's really one rule underneath all of them: each one solves a specific problem — understand why before you apply it blindly. Good code isn't code that follows every rule; it's code written by someone who knows when a rule applies and when it doesn't.

If you've got a tip you rely on that isn't on this list, I'd genuinely like to hear it.

DEV Community: mt-laid

38 Dart & Flutter Tips That Actually Make a Difference in Production

Part 1: Modern Dart Language Features

1. Stop reaching for ! after a null check

2. Build your lists declaratively

3. Use switch with pattern matching instead of nested if/else

4. Use destructuring to unpack values in one step

5. async/await aren't always necessary

6. Explain why you're ignoring a lint warning

Part 2: Testing You Can Actually Trust

7. Write assertions that read like a sentence

8. Don't drag unnecessary dependencies into your tests

9. Golden tests for catching visual regressions

10. Use mocktail over mockito for new projects, and fake_async for time-dependent tests

Part 3: Debugging & Naming

11. Let your logger do its job

12. Name Sliver widgets clearly

13. Use dedicated widgets instead of single-purpose Containers

14. Use dot shorthand when the type is already obvious

Part 4: Performance — Beyond the Basics

15. Stop worrying about shader jank — but know why

16. Use long-lived isolates for repeated work, not compute() in a loop

17. Reach for a custom RenderObject only when layout widgets genuinely can't do it

18. --obfuscate --split-debug-info — and actually keep the output

19. Prove memory leaks instead of guessing at them

20. Keep heavy computations out of build()

21. Use compute() for genuinely intensive work

22. Don't turn simple conditions into nested ternaries

23. Prefer widget classes over widget-returning methods

24. A small let() extension can simplify transformations

25. Let static analysis catch problems before code review

26. Use spread operators when composing lists

27. Give meaningful numbers a name

28. Use castOrNull only when invalid data should behave like missing data

29. Use extension types to give dynamic data a domain-specific API

30. Let build_runner watch generated code

31. Use hooks when lifecycle boilerplate becomes repetitive

Part 6: Dart Language — Genuinely Advanced Features

32. Sealed classes for state that can't be invalid by construction

33. Extension types for zero-cost domain types

34. Deferred imports for real code-splitting

Part 7: A Few Extra Useful Tips

35. Tag every hardcoded string so localization never loses one

36. Put BuildContext lookups behind extensions

37. Strict analysis_options.yaml, with CI failing on any warning

38. Keep business logic completely separate from widgets

The Takeaway

1. Stop reaching for `!` after a null check

3. Use `switch` with pattern matching instead of nested `if/else`

5. `async/await` aren't always necessary

10. Use `mocktail` over `mockito` for new projects, and `fake_async` for time-dependent tests

13. Use dedicated widgets instead of single-purpose `Container`s

16. Use long-lived isolates for repeated work, not `compute()` in a loop

17. Reach for a custom `RenderObject` only when layout widgets genuinely can't do it

18. `--obfuscate --split-debug-info` — and actually keep the output

20. Keep heavy computations out of `build()`

21. Use `compute()` for genuinely intensive work

24. A small `let()` extension can simplify transformations

28. Use `castOrNull` only when invalid data should behave like missing data

30. Let `build_runner` watch generated code

36. Put `BuildContext` lookups behind extensions

37. Strict `analysis_options.yaml`, with CI failing on any warning