medusajs/medusa · warning
Unable to load resources for module
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.
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
- Config is not available for the input object.
- Invalid default export found in
- Invalid modules configuration. Should be an array or object.
- Job registration requires config.name. Received
- Layout file has no 'config' named export. Export 'export…
AI-assisted analysis of medusajs/medusa@5e06e544a2 (2026-08-27).
Data as JSON: /api/errors/c7ddd81e3ddcd2ce.
Report an issue: GitHub.
Appendix: 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)