Unable to load resources for module ${modulePath} automagica

Error message

Unable to load resources for module ${modulePath} automagically. ${e.message}

What it means

loadResources is the modules-sdk's auto-loader that conventionally discovers models, migrations, services, and repositories inside a module directory by scanning subfolders. If any part of that filesystem scan/require throws, the whole module resource set is discarded and an empty ModuleResource is returned with this warning, which usually surfaces later as 'module not found' or resolution errors.

Source

Thrown at packages/core/modules-sdk/src/loaders/utils/load-internal.ts:690

    // if a module service is provided, we generate a joiner config
    if (moduleService) {
      generateJoinerConfigIfNecessary({
        moduleResolution,
        service: moduleService,
        models: potentialModels,
      })
    }

    return {
      services: potentialServices,
      models: mikroOrmModels,
      repositories: potentialRepositories,
      loaders: finalLoaders,
      moduleService,
      normalizedPath,
    }
  } catch (e) {
    logger.warn(
      `Unable to load resources for module ${modulePath} automagically. ${e.message}`
    )

    return {} as ModuleResource
  }
}

async function runLoaders(
  loaders: Function[] = [],
  {
    localContainer,
    container,
    logger,
    resolution,
    loaderOnly,
    keyName,
    providerOptions,
  }

View on GitHub (pinned to 5e06e544a2)

Solutions

Check the appended ${e.message} — it names the underlying require/scan failure; fix that first (missing file, bad import, wrong path)
Verify the module's `resolve` in medusa-config.js points to the module root that contains src/services, src/models, src/repositories
Ensure every file in the module's src tree imports cleanly (run the module package's build/tests independently)
For non-standard layouts, export an explicit `resources` property (service, models, etc.) from the module instead of relying on automagic discovery

Example fix

// before (medusa-config.js)
modules: [{ resolve: "./src/modules/my-module", options: {} }]
// error if folder actually is src/modules/myModule

// after
modules: [{ resolve: "./src/modules/myModule", options: {} }]

Defensive patterns

Strategy: try-catch

Validate before calling

// before registering
const fs = require("fs")
const p = path.resolve(modulePath, "src", "services")
if (!fs.existsSync(p)) throw new Error(`Module ${modulePath} missing src/services`)

Try / catch

try {
  await MedusaModule.migrateUp(moduleKey, moduleConfig)
} catch (e) {
  logger.error(`module load failed: ${e.message}`) // warning already swallowed details in e.message
  throw e
}

Prevention

Validate module resolve paths in medusa-config.js at startup
Keep module folder layout conventional (src/services, src/models)
Import-test each module file in CI so bad imports fail the build

When it happens

Trigger: Registering a module via medusa-config.js modules entry whose resolution points to a directory with unexpected structure (no src, unexpected file that throws at import time, case-mismatched folder names), or a module path that cannot be resolved/required.

Common situations: Local module development with a wrong `resolve` path; a file inside the module that throws at import (e.g. imports a missing dependency); renaming module folders without updating medusa-config; publishing a module package without its src/services and src/models folders.

Related errors

AI-assisted analysis of medusajs/medusa@5e06e544a2 (2026-08-27). Data as JSON: /api/errors/c7ddd81e3ddcd2ce. Report an issue: GitHub.