Why are we not generating the .medusa/types folder in production mode ?

[adevinwild]

Hi team!

I have a quick question. I was wondering why we aren't generating the types when executing the ⁠medusa build command? With ⁠medusa develop, we've been getting type inference for Custom Modules since [version 2.5.0] (https://github.com/medusajs/medusa/releases/tag/v2.5.0) (not sure about the version level though), which allows us to avoid explicitly casting custom services used elsewhere.

// ℹ️ Before V2.5.0, we were used to explicitly cast modules like this

import { BLOG_MODULE } from "../../modules/blog"
import type BlogModuleService from "../../modules/blog/service"

// ...
const blogModuleService = container.resolve<BlogModuleService>(BLOG_MODULE) 

// ✅ After V2.5.0, we can count on the `modules-bindings.d.ts` file type inference to get the right type

import { BLOG_MODULE } from "../../modules/blog"

// ...
const blogModuleService = container.resolve(BLOG_MODULE)

---

However, when building for production, if the necessary .medusa/types folder hasn't been generated beforehand, we might encounter a build error because the type won't be resolved, potentially leading to a TypeScript build error due to the unknown type returned by the container.resolve

Just wanted to know the reasoning behind this and what about having some new CLI options to generate the types, to make sure to continue to offer this improvement at the DX level without it being ultimately punished at the time of the build in prod

[thetutlage]

Hello @adevinwild

Yes, this has to be fixed. Lemme look into it in the coming days 💪

[mvarchdev]

Hey! Looking forward for this! Created also #12677

[mvarchdev]

@thetutlage Hello! What is the status of this? We would need this really urgently. We are currently trying to implement it by ourselves, but no luck so far...

[mvarchdev]

Hello @thetutlage ! Pinging again, probably you did not see notif!

[adevinwild]

Hello @thetutlage ! Pinging again, probably you did not see notif!

Hey @mvarchdev
Harminder Virk no longer works at Medusa 🙌

I'm wondering if we can make a PR related to the CLI for this 🤔

[mvarchdev]

Hello @adevinwild - thanks for the info, did not know that! - As we really needed short-term and quicl solution for this, we created workaround where we spinup postgresql db and then generate types. In general, this is not very nice, but current code does not allow to generate types without running postgres as it need to run loaders or something like that. The correct implementation would mean that we need to refactor this mechanism. Also, as we use types in the code-base, we need them to be commited, because if they are not there, the type-generation fails (as it will load modules during that).

Also, we found several other issues... here are all issues:

• You cannot generate types without having postgres up, which is completely wrong...
• When you use generated types in the code, and the types are not commited (so types are missing) and then you run type generation, it will fail. So, deadlock
• As we are commiting types, everytime we run type-generation, it will be same types, but different order of types or/and attributes in that types (so one type before other, or/and attribute before other in that type). It is weird but as the graphql schema is generated asynchronically, I think it makes sense. So we created sorting script for that also...

[adevinwild]

Just in case for posterity
#12677 (comment)