Feat: Seeding database

[JoaoAlem]

This PR solves #8

[JoaoAlem]

Hello everyone.

This PR adds the code and scripts to seed the database.
It's still ins draft, because it's not done yet.
For everyone who wants to contribute in this PR, you can find a seed.ts file in databases folder.
I left a lot of TODO in the code, so i can guarantee you won't be lost in the code 😄

[JoaoAlem]

Now, this PR is ready to merge.
Feel free to make any critics or do fixes, or ask me to do fixes in the code.

[ernestoresende]

I highly recommend tsx instead of a custom loader for Node.js. In a perfect world, TypeScript would be treated as a first class citizen and automatically transpiled at runtime (both Deno and Bun achieve this), but Node.js precedes TypeScript by I few years, so these and other module related annoyances are quite common.

Note
Remember to add tsx as a devDependency on the @open-visit/database workspace.

Suggested change

	"db:seed": "node --loader esbuild-register/loader -r esbuild-register ./seed.ts"
	"db:seed": "pnpm dotenv tsx ./seed.ts"

[ernestoresende]

As counterintuitive as it seems, $inferSelect is actually preferable for a better representation of the type annotations here.

This is because, from TypeScript's perspective, if in Drizzle schema.ts we declare that those primary keys are notNull() but also defaultRandom(), the type inference understands that this value can be left as undefined, because it will be autogenerated by the database engine, which is technically a correct inference.

In the seeding script case however, we need to references to these ID's directly because we're sequentially creating relational data, so we need to reference created ID's in subsequent objects.

$inferSelect will always have id: string instead of id?: string | undefined because, from a selection perspective, an id will never be undefined (it was either defined at runtime, or by the database engine).

Suggested change

	const employeeUserData: (typeof user.$inferInsert)[] = []
	const condominiumUserData: (typeof user.$inferInsert)[] = []
	const condominiumData: (typeof condominium.$inferInsert)[] = []
	const companyData: (typeof company.$inferInsert)[] = []
	const departmentData: (typeof department.$inferInsert)[] = []
	const employeeData: (typeof employee.$inferInsert)[] = []
	const schedulingData: (typeof scheduling.$inferInsert)[] = []
	const employeeUserData: (typeof user.$inferSelect)[] = []
	const condominiumUserData: (typeof user.$inferSelect)[] = []
	const condominiumData: (typeof condominium.$inferSelect)[] = []
	const companyData: (typeof company.$inferSelect)[] = []
	const departmentData: (typeof department.$inferSelect)[] = []
	const employeeData: (typeof employee.$inferSelect)[] = []
	const schedulingData: (typeof scheduling.$inferSelect)[] = []

[ernestoresende]

This can be omitted, since we're already injecting the environment variable trough the process spawn with the package.json script.

Suggested change

	import * as dotenv from "dotenv";
	dotenv.config({ path: "./.env" });

[ernestoresende]

faker-js/faker is currently in the process of deprecating the usage of phone.number(<string_pattern>). They instead recommend using either string.numeric, or a Regular Expression.

We don't really care much about the validity of those phone numbers for test data, so I believe prefixing the country code and the ninth digit from Brazil's phone numbers with subsequent 8 character long string of random numbers should be enough.

Suggested change

	phoneNumber: faker.phone.number("55###########"),
	phoneNumber: `559${faker.string.numeric(8)}}`,

[ernestoresende]

@JoaoAlem Excellent work with this 🚀

Left a few revisions above that hopefully I'll agree with. Let me know if you need any further help 😄