#Building backend source fails due to TS18046 error with custom module

10 messages · Page 1 of 1 (latest)

normal dock
#

I'm struggling with deploying the application. When it's building I get:

info:    Starting build...
info:    Compiling backend source...
info:    Removing existing ".medusa/server" folder
info:    Compiling frontend source...
src/workflows/hooks/create-customer.ts:31:40 - error TS18046: 'customerExtensionsService' is of type 'unknown'.

31     const newCustomerExtension = await customerExtensionsService
                                          ~~~~~~~~~~~~~~~~~~~~~~~~~

customerExtensionsService is a service created in the module directory.

I reproduced that error locally by removing .medusa/types directory and runnning medusa build

In development mode, when the types are generated everything works fine.

Any clues what might be wrong?

stuck crane
#

Maybe you can run medusa generate types and then retry not specific to medusa but they are differences between a dev and a prod build in many framework and with typescrypt even more

normal dock
#

Medusa CLI doesn't have such command. It generates types on medusa dev. Running this command on before building doesn't feel right 😅

eager glen
#

Hi @normal dock
When you build locally the project are you getting some type inference on the customerExtensionsService or are you getting the unknown type too ?
Also can you share how do you resolve the service please on top of your Medusa version 🙌

normal dock
#

When I build after development locally it works well, because types are already generated in the .medusa/types. However when I remove it and run medusa build it fails.
I'm using 2.8 version of medusa.

Maybe I shouldn't resolve my custom module inside the hook's callback....

Here is the code:

createCustomersWorkflow.hooks.customersCreated(
  async ({ customers, additional_data }, { container }) => {
    if (!additional_data) {
      throw new MedusaError(MedusaError.Types.INVALID_DATA, 'error');
    }

    const customerExtension = CustomerExtensionCreateSchema.safeParse(additional_data);
    if (!customerExtension.success) {
      throw new MedusaError(
        MedusaError.Types.INVALID_DATA,
        `${customerExtension.error.errors.map((error) => error.message).join(', ')}`,
      );
    }

    const customerExtensionsService = container.resolve(CUSTOMER_EXTENSION_MODULE);
    const newCustomerExtension = await customerExtensionsService
      .createCustomerExtensions(customerExtension.data)
      .catch(() => {
        return StepResponse.permanentFailure(undefined);
      });

    const link = container.resolve('link');
    await link
      .create({
        [Modules.CUSTOMER]: {
          customer_id: customers[0].id,
        },
        [CUSTOMER_EXTENSION_MODULE]: {
          customer_extension_id: newCustomerExtension.id,
        },
      })
      .catch(() => {
        return StepResponse.permanentFailure(undefined, {
          customerExtensionId: newCustomerExtension.id,
        });
      });

    return new StepResponse('create-customer-extension-link', { customerExtensionId: newCustomerExtension.id });
  }
)
eager glen
#

For me, you should resolve this issue by changing this line :

    const customerExtensionsService = container.resolve(CUSTOMER_EXTENSION_MODULE);

To the following one :

    const customerExtensionsService = container.resolve<CustomerExtensionService>
(CUSTOMER_EXTENSION_MODULE);

By casting the type of the service resolved, you're making sure that your constant has always the right type and no longer have an unknown value. I think that by being more explicit like this it should not trigger that error on build 🤔

#

But true that when you run the dev mode, you're getting the .medusa/types/ folder but it's weird that it's not saved when building for production mode indeed

#

I remember that the release that introduced the type inference on custom modules was like some sort of "experimental" (I may be wrong) Type-Hinting for Custom Modules Services in 2.5.0 was not experimental but a first iteration on it , so you might have found an issue related to it, and why it's not packed in the final production build would be a great question

normal dock
#

That did the job! Thank you very much.

eager glen