Way to extend/modify columns-definition.ts for import?

[genox]

Hi,

Is there a way to override src/strategies/batch-jobs/product/types/columns-definition.ts short of applying a patch on package install? Could be very handy to handle importing and exporting custom attributes.

I read about https://docs.medusajs.com/development/batch-jobs/customize-import and was considering cloning the batch-import/export completely since it does a great job, but there's a lot of local imports from the main codebase that I'm afraid will be very hard to resolve. So patching the column def might be a quick win.

[aidensgithub]

Hey @genox did you find any better way of extending it by chance?

[genox]

Unfortunately not, so far. All things considered, patching the file is working well for my purposes. Only issue is that with each release, patch files need to be considered. I wish there was a cleaner solution or some boilerplate for this use case (which seems to be a common one).

[aidensgithub]

It seems like that's the way it is indeed. Thanks!

[srindom]

I read about https://docs.medusajs.com/development/batch-jobs/customize-import and was considering cloning the batch-import/export completely since it does a great job, but there's a lot of local imports from the main codebase that I'm afraid will be very hard to resolve. So patching the column def might be a quick win.

The recommended approach is to use a custom strategy to take care of the import which is what is outlined in the docs entry you link here. Could you elaborate a bit on your concern?

[genox]

My requirement is simply to add one more field and add that to the vanilla import job. Figuring out the "proper way" requires more time than I currently have to build and test. Especially because there are unknowns since I am not an expert. So I take the easy way out to get the feature I need in order to continue working on other things.

I was reading the linked page but by the end of it, I had no more idea about how to add a custom field to the import than I had when starting it.

I completely understand that it is impossible to add an example for every possible use case. On the other hand, the knowledge required to get something "easy" done is not trivial, especially when starting out, so that explains people patching core files. I came across this as a "solution" on Discord in some threads about modding other core stuff as well, which probably indicates that the complexity is large and patching seems trivial compared to building out the entire thing from scratch. Especially when one doesn't know where to even start, really.

Of course if you're a seasoned medusa dev then you can figure you're way to a solution out intuitively. I'm not really there yet. ;)

In an ideal world, the import job would pick up the existing fields and handle it dynamically - therefore picking up new fields without requiring to hardcode anything. But that is a lot of complexity, too, and since the level of customisation is basically endless.. probably not that easy, either.

[dpdenton]

@srindom is there a reason we can't just extend the medusajs ProductImportStrategy / ProductExportStrategy as this obviously also extends the AbstractBatchJobStrategy..

That was my first attempt but doesn't seem to work