Issue generating auth-schema
@Better Auth
❯ pnpm dlx @better-auth/cli generate
⠋ preparing schema...file:///Users/coco/Library/Caches/pnpm/dlx/2630d1115258bcf0a385078b8f531124ceb8d54daa6ed354a6419c4761723963/198b27522a9-139f7/node_modules/.pnpm/@better-auth+cli@1.3.6_kysely@0.28.5_zod@4.0.17/node_modules/@better-auth/cli/dist/index.mjs:2172
return typeMap[type][databaseType];
^
TypeError: Cannot read properties of undefined (reading 'pg')
at getType (file:///Users/coco/Library/Caches/pnpm/dlx/2630d1115258bcf0a385078b8f531124ceb8d54daa6ed354a6419c4761723963/198b27522a9-139f7/node_modules/.pnpm/@better-auth+cli@1.3.6_kysely@0.28.5_zod@4.0.17/node_modules/@better-auth/cli/dist/index.mjs:2172:27)
at file:///Users/coco/Library/Caches/pnpm/dlx/2630d1115258bcf0a385078b8f531124ceb8d54daa6ed354a6419c4761723963/198b27522a9-139f7/node_modules/.pnpm/@better-auth+cli@1.3.6_kysely@0.28.5_zod@4.0.17/node_modules/@better-auth/cli/dist/index.mjs:2200:18
at Array.map (<anonymous>)
at generateDrizzleSchema (file:///Users/coco/Library/Caches/pnpm/dlx/2630d1115258bcf0a385078b8f531124ceb8d54daa6ed354a6419c4761723963/198b27522a9-139f7/node_modules/.pnpm/@better-auth+cli@1.3.6_kysely@0.28.5_zod@4.0.17/node_modules/@better-auth/cli/dist/index.mjs:2198:28)
at generateSchema (file:///Users/coco/Library/Caches/pnpm/dlx/2630d1115258bcf0a385078b8f531124ceb8d54daa6ed354a6419c4761723963/198b27522a9-139f7/node_modules/.pnpm/@better-auth+cli@1.3.6_kysely@0.28.5_zod@4.0.17/node_modules/@better-auth/cli/dist/index.mjs:2456:12)
at Command.generateAction (file:///Users/coco/Library/Caches/pnpm/dlx/2630d1115258bcf0a385078b8f531124ceb8d54daa6ed354a6419c4761723963/198b27522a9-139f7/node_modules/.pnpm/@better-auth+cli@1.3.6_kysely@0.28.5_zod@4.0.17/node_modules/@better-auth/cli/dist/index.mjs:2499:24)
Node.js v22.13.1
auth:
export const auth = betterAuth({
database: drizzleAdapter(db, {
provider: "pg",
})
})
5 Replies
Hi there! It looks like you’re hitting a known issue with the Drizzle adapter when using the "pg" provider in combination with an array field type. When the CLI encounters an array field (i.e. a field defined as "string[]"), it attempts to access a type mapping for "pg" that isn’t defined, which leads to the error you're seeing ("Cannot read properties of undefined (reading 'pg')") [1].
A couple of suggestions:
- Verify if the array field is necessary. If it’s not critical, removing it from your configuration may allow the schema generation to complete successfully.
- Alternatively, consider adjusting your configuration field type to one that’s currently supported for the "pg" provider until this bug is addressed.
This issue has been tracked on our GitHub (see Document 1), and the team is working to improve support for array types in future releases. Let me know if you have any other questions!
Sources:
[1] the cli can't generate drizzle schema with array type
GitHub
better-auth/better-auth
The most comprehensive authentication framework for TypeScript - better-auth/better-auth
GitHub
the cli can't generate drizzle schema with array type · Issue #118...
Is this suited for github? Yes, this is suited for github To Reproduce Follow setup instructions Add a custom field with the "string[]" type (use the drizzle adapter) Run pnpx @better-aut...
@Better Auth Another quick question. When i add in additional fields for example:
additionalFields: {
firstName: {
type: "string",
input: true,
required: true,
returned: true,
},
lastName: {
type: "string",
input: true,
required: true,
returned: true,
},
isActive: {
type: "boolean",
input: false,
required: true,
defaultValue: true,
},
},
For the user object. It doesn't get reflected in the openapi documentation nor does it get updated in the endpoints like /update-user. Is there a way to update the documentation?
Hey there! This is a common question. The OpenAPI plugin initially didn’t include additionalFields in the generated schema, but a recent update now includes them properly [16]. If your documentation isn’t reflecting your custom fields (like firstName, lastName, or even isActive), please check the following:
1. Make sure you’re using the latest version of Better Auth that contains the OpenAPI enhancements. The patch [16] added support for including additional user fields with correct types, defaults, and required properties.
2. Remember that fields configured with input: false (like your isActive field) aren’t meant to be passed by the user. For endpoints such as /update-user, only fields with input: true will be accepted for updates by default. So if you need a field to be updateable and show up in the documentation as an updatable property, it should have input: true [17].
If you upgrade to the latest version and adjust the configuration as needed, your additional fields should both update the OpenAPI docs and work as expected in the endpoints. Hope that helps!
Sources:
[16] feat(open-api): include additional fields
[17] TypeScript | Better Auth
GitHub
Build software better, together
GitHub is where people build software. More than 150 million people use GitHub to discover, fork, and contribute to over 420 million projects.
GitHub
feat(open-api): include additional fields by Kinfe123 · Pull Reque...
closes #3263
Summary by cubic
Added support for including additional user fields in the generated OpenAPI schema, with correct types, defaults, and required status.
New Features
User-defined add...
TypeScript | Better Auth
Better Auth TypeScript integration.
@Better Auth Only the models are being updated. Not the endpoints. even if the input: true is available for the additional fields for endpoints like /update-user it does'nt show up. Is there a way to add over there as well?
Hi there! Currently, when you update a user, the additional fields are indeed getting saved in the database, but the /update-user endpoint’s response doesn’t include them yet. This is a known limitation—in our recent fixes, we improved the type inference and updating logic for additional fields [4], but the response payload hasn’t been updated to include these extra fields.
As a workaround, you can retrieve the complete user data (with the additional fields) by calling a subsequent endpoint (e.g., /get-session or /get-user) immediately after the update. We're aware that having these fields directly in the update response would be more convenient and have an enhancement request open for it [28].
I hope this helps, and thanks for raising the issue!
Sources:
[4] fix: update user should infer additional fields properly
[28] Additional fields should also be there in response body
GitHub
better-auth/better-auth
The most comprehensive authentication framework for TypeScript - better-auth/better-auth
GitHub
Additional fields should also be there in response body · Issue #3...
Is this suited for github? Yes, this is suited for github Is your feature request related to a problem? Please describe. Its really hard and a hassle to get the additional fields if have them in de...