[Portability] - Workspace Drivers Architecture

Adds an ‘npm collect:drivers‘ script

• Scans for `{driverName}.{driverType}.ts` files

• Searches within ‘/drivers/‘ directories

Supported {driverType} values:

• db - Data persistence (e.g. → ‘@db/mongoose‘)

• auth - Authentication (e.g. → ‘@auth/clerk‘)

• files - File Storage (e.g. → ‘@files/uploadthing‘)

• email - Sending emails (e.g. → ‘@email/resend‘)

Provider selection is configured in ‘@app/config’

{
   db: 'mongoose', // from options 'mongoose' | 'supabase' | ...
   auth: 'clerk', // options 'clerk' | 'supabase' | 'workos' | ...
}

Driver packages ‘@{driverType}/driver’ re-export the selected provider’s core modules:

• ‘@db/driver‘ → insert / update / delete methods from ‘@db/mongoose‘

• ‘@auth/driver‘ → SignIn / SignUp / useUser() / … from ‘@auth/clerk‘

• All driver options must conform to a common driverType structure, enforced with Zod

Key Benefits

• ❇️ Uses Zod to ensure a common interface for driver options

  • Alternative to just Typescript for enforcing the driver “contract”

• ❇️ Swapping providers becomes a config change, not a rewrite

  • Business logic stays mostly untouched

• ❇️ You can still use the drivers separately by importing from them directly

  • e.g. ‘@db/mongoose‘ instead of ‘@db/driver‘ in some places

  • Enables you to use different provider if required

    • e.g. during a migration to a new provider

🚧 Caveats

• The architecture and script supporting this workspace driver architecture are finished,

• BUT, most of the actual drivers are still in progress:

  • [Plugin] - @db/driver

  • [Plugin] - @auth/driver

• You can already add your own custom drivers if you think this is an interesting approach

  • Have a look at ‘mock.db.ts‘ as an example