Mixing modular Drift codegen in feature package with classic builder (database.g.dart) in app database. #3693

CalvinGonsalves · 2025-10-21T20:17:58Z

CalvinGonsalves
Oct 21, 2025

Hello,

TL;DR: Can I keep my app on the classic single database.g.dart build while moving one feature at a time into its own package that uses modular Drift code generation (*.drift.dart)? If yes, what’s the recommended way to wire that package into my existing app database?

Context:

The app today has many tables and DAOs generated the old way into a single database.g.dart. The goal is to incrementally extract features into separate packages and each package will use the modular codegen to produce *.drift.dart files.
I want to consume such packages without switching the app to modular yet.

What I've tried:

Suppose I have a feature package audit_schema and have table and dao files like below:
Table

// audit_schema/lib/src/audit_table.dart

import 'package:drift/drift.dart';

class Audit extends Table {
  IntColumn get id => integer().autoIncrement()();
  TextColumn get name => text()();
}

DAO

// audit_schema/lib/src/audit_dao.dart

import 'package:audit_schema/src/audit_dao.drift.dart';
import 'package:audit_schema/src/audit_table.drift.dart';
import 'package:drift/drift.dart';
import 'audit_table.dart';

@DriftAccessor(tables: [Audit])
class AuditDao extends DatabaseAccessor<GeneratedDatabase> with $AuditDaoMixin {
  AuditDao(super.attachedDatabase);

  Future<List<AuditData>> get all => audit.all().get();
}

I run the codegen and the audit_table.drift.dart and audit_dao.drift.dart files are generated.

I export the dao and table file from audit_schema.dart

// audit_schema/lib/audit_schema.dart

export 'src/audit_table.dart';
export 'src/audit_table.drift.dart';
export 'src/audit_dao.dart';
export 'src/audit_dao.drift.dart';

In the Application code, I have the database defined as:

import 'package:app/user_dao.dart';
import 'package:app/user_table.dart';
import 'package:drift/drift.dart';
import 'package:audit_schema/audit_schema.dart';  // Added because generated database gives error without it.

part 'database.g.dart';

@DriftDatabase(
  tables: [User],
  daos: [UserDao],
  include: {'package:audit_schema/audit_schema.dart'},
)
class MyDatabase extends _$MyDatabase {
  MyDatabase(super.e);

  @override
  int get schemaVersion => 1;
}

where the user table and dao files are also defined in the app as :

// app/lib/user_table.dart
import 'package:drift/drift.dart';

class User extends Table {
  IntColumn get user => integer()();
  TextColumn get bearerToken => text()();
}

import 'package:app/database.dart';
import 'package:app/user_table.dart';
import 'package:drift/drift.dart';

part 'user_dao.g.dart';

@DriftAccessor(tables: [User])
class UserDao extends DatabaseAccessor<MyDatabase> with _$UserDaoMixin {
  UserDao(super.attachedDatabase);
}

When generating the database.g.dart file with the classic builder in the app, I received an error in that file when trying to reference the Audit table file, so I had to import the audit_schema.dart from the package.
Also, I noticed that the generated database file uses its own $AuditTable and AuditData classes instead of the ones from the audit_table.drift.dart.

I wanted to know if what I have tried is the correct approach or I am missing something.

Thanks in advance.

simolus3 · 2025-10-22T07:28:32Z

simolus3
Oct 22, 2025
Maintainer

Hi! At the moment you would unfortunately have to migrate everything to the modular generation mode (the reason is that by design, the non-modular builder thinks it's fine to generate everything into a single file). Another thing worth noting is that for multi-package setups, the inner packages need to have a regular (non-dev) dependency on drift_dev for the modular builder in the main package to see their definitions.

I've never tried this, but I think one hybrid that may work and could make the migration easier is to:

Enable the modular builder for the main database file.
But for your existing DAOs that haven't been migrated to separate packages yet, keep the default builder.

That would mean fewer changes to make at once. I've never tried this with shared code, but e.g. the drift documentation site uses both modular and non-modular builders depending on the input file path.

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Mixing modular Drift codegen in feature package with classic builder (database.g.dart) in app database. #3693

Uh oh!

{{title}}

Uh oh!

Replies: 1 comment

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Mixing modular Drift codegen in feature package with classic builder (database.g.dart) in app database. #3693

Uh oh!

CalvinGonsalves Oct 21, 2025

Context:

What I've tried:

Replies: 1 comment

Uh oh!

simolus3 Oct 22, 2025 Maintainer

CalvinGonsalves
Oct 21, 2025

simolus3
Oct 22, 2025
Maintainer