Document "dependencies" option in Modules(if stable)

[SteelRazor47]

What Medusa version and documentation are you using?

v2

Preliminary Checks

• This issue is not a duplicate. Before opening a new issue, please search existing issues: https://github.com/medusajs/medusa/issues

Issue Summary

Hi, after a day of trying to figure out a way to resolve the product module inside my fulfillment provider for more info i found out in this issue #10487 about the "dependencies" attribute. (unfortunately i found the discussion about the data needed in create fulfillment too late)
Is it going to be a stable feature? Because it seems to contrast the whole module isolation thing going on with v2, and the docs more or less say that you cant do this.

If so it would be nice to have it mentioned in the docs.

How can this issue be resolved?

No response

Are you interested in working on this issue?

• I would like to fix this issue

[riqwan]

Hey @SteelRazor47,

dependencies are usually more for global services like logger or eventBus and not for other modules like product.

If you need more information on the fulfillment, it should be passed as a context data that we pass to the providers from the workflows. Can you share what details you'd like to see in your provider thats not already being passed?

[riqwan]

Also, regarding docs, what exactly would you like to see mentioned there? Is this around the dependencies concept or the provider "data" aspect?

[SteelRazor47]

Thanks for the quick reply, for the docs i was talking about the dependencies concept. Imho it could be a subsection of "Module Isolation", stating that it's discouraged in favor of workflows when possible.
BUT only if adding commerce modules to it isn't going to be forbidden down the line, since adding commerce modules is the main use I'd expect from other devs if they knew about it and that would definetely cause issues.

For the provider data my integration specifically requires variant.weight(dimensions would be nice too), variant.hs_code, variant.origin_country, order.fulfillment_status/payment_status and order.created_at(which i can replace with fulfillment.created_at in my case, but it would be nice to have the full OrderDTO available).
It's odd that these properties, that mostly relate only to shipments, werent included.

[sradevski]

I think the docs clearly state that if you need cross-module data, you should use a workflow to collect and pass the data. @shahednasser I'll leave this to you to decide if there is something we should add or change in the docs, but otherwise we can close it.

[shahednasser]

Hey @SteelRazor47 your points regarding the fulfillment data is very justifiable, as those currently aren't clear and I believe they're in the works to be improved. There should be some improvement already in the latest release, and you can see an example of creating a fulfillment provider in this guide.

Will close this issue for now. Feel free to let us know if you have other comments or questions.

[SteelRazor47]

@sradevski Yeah that's how I do everything else in my custom services/logic and havent had a problem so far, I think the isolation stuff in v2 has been wonderful, great job 👍 . The only problem is in the fulfillment provider(and possibily other custom providers like auth that integrate directly with the core flows and have a rigid API) since, correct me if I'm wrong, there isn't a feasible way to inject additional data from other modules(like Product) before createFulfillment is called. The only other way(besides my hack) i could think of would be to create a "fake" fulfillment with all the data i receive from medusa, then immediately run a subscriber to fetch the missing stuff and only then execute the real logic of the fulfillment provider, which kinda defeats the purpose of the module imho.

But I'm sure it wont be a problem in the future once the interfaces for the providers have been refined. I'm totally fine with the dependencies workaround for now.

[SteelRazor47]

@shahednasser I saw it ty, I've already upgraded to 2.1.3. I'm only missing a few fields now, namely hs_code and origin_country(which i dont care about right now, they are only needed by the api so it's really a non-issue).
I really appreciate the work on the v2 docs btw 👍 They are a bit scattered in some places but they are miles better than v1 imho.