Open goldcaddy77 opened 3 years ago
@dzhelezov I think this was happening because I was loading the metadata class here:
https://github.com/goldcaddy77/warthog/blob/main/src/decorators/WarthogField.ts
In 3.0 I've changed the metadata pipeline to instead write the metadata properties onto the class and then subsequently read them when I'm doing codegen:
https://github.com/goldcaddy77/warthog/blob/beta/src/decorators/WarthogField.ts
I think this means you'll be able to load up the models without worrying about Config getting pulled in.
Can you give me a quick example of how I'd test this?
Simply import User
from say https://github.com/goldcaddy77/warthog/blob/main/examples/01-simple-model/src/user.model.ts and try to save it:
import { User } from '01-simple-model/dist/user.model'
import { getManager } from 'typeorm'
async function createUser() {
const u = new User()
await getManager().save<User>(u)
}
createUser().catch((e) => console.error(e)).then(() => console.log('Done'))
The code above should work without WARTHOG_* variables being set (but the db with the typeorm defaults should be accepting connections)
Make config more forgiving. We oftentimes import wathog-decorated model classes in external independent data loaders, and it's a bit awkward to set WARTHOG_* env variables just to be able to use the classes (as config() is picked up through the decorators and throws an error if the warthog env variables are not set). It would be nice (but not strictly necessary) to be able to pack the model classes into a lightweight dependency with only typeorm decorators
CC @dzhelezov