[MobX] minified error nr: ${error}${args.length ? " " + args

Error message

[MobX] minified error nr: ${error}${args.length ? " " + args.map(String).join(",") : ""}. See mobx.js.org/errors

What it means

This is the production-mode branch of MobX's die(): when __DEV__ is false, MobX throws a deliberately terse 'minified error nr' message containing only the numeric error code and raw arguments, pointing to mobx.js.org/errors. The full explanation is stripped to keep the bundle small, so the code itself is the diagnostic.

Source

Thrown at packages/mobx/src/errors.ts:99

        return (
            `Cannot apply '${annotationType}' to '${name}' (kind: ${kind}):` +
            `\n'${annotationType}' can only be used on properties with a function value.`
        )
    },
    44(annotationType) {
        return `'${annotationType}' can only be used with 'makeObservable'`
    }
} as const

const errors: typeof niceErrors = __DEV__ ? niceErrors : ({} as any)

export function die(error: string | keyof typeof errors, ...args: any[]): never {
    if (__DEV__) {
        let e: any = typeof error === "string" ? error : errors[error]
        if (typeof e === "function") e = e.apply(null, args as any)
        throw new Error(`[MobX] ${e}`)
    }
    throw new Error(
        `[MobX] minified error nr: ${error}${
            args.length ? " " + args.map(String).join(",") : ""
        }. See mobx.js.org/errors`
    )
}

View on GitHub (pinned to 01211a698b)

Solutions

Reproduce locally with a development build (NODE_ENV=development) to get the full message
Take the number after 'minified error nr:' and look it up at mobx.js.org/errors or in packages/mobx/src/errors.ts niceErrors table
Search the codebase for the failing API call once the code is decoded and fix the invariant violation
Enable source maps and stack traces in prod monitoring to locate the throwing call site

Example fix

// before (prod output)
Error: [MobX] minified error nr: 12. See mobx.js.org/errors
// after (debug locally)
NODE_ENV=development npm run dev  # full message: [MobX] <detailed explanation>

Defensive patterns

Strategy: try-catch

Validate before calling

null

Type guard

function isMinifiedMobxError(e: unknown): e is Error {
    return e instanceof Error && e.message.startsWith('[MobX] minified error nr:')
}

Try / catch

try {
    runReaction()
} catch (e) {
    if (e instanceof Error && e.message.startsWith('[MobX] minified error nr:')) {
        const nr = e.message.match(/nr:\s*(\S+)/)?.[1]
        console.error(`MobX prod error ${nr} — decode at mobx.js.org/errors`)
    } else throw e
}

Prevention

Test critical flows with development builds where full messages are thrown
Keep a map of niceErrors (packages/mobx/src/errors.ts) handy for prod triage
Enable source maps in error monitoring to find call sites
Reproduce prod-only failures locally with NODE_ENV=production but unminified bundles

When it happens

Trigger: Any MobX invariant violation (same set as the dev-mode die) occurring in a production build: e.g. invalid autorun/reaction/computed arguments, wrong decorator targets via assert20223DecoratorType, invalid extendObservable usage — but with the descriptive message compiled out.

Common situations: Bundling with NODE_ENV=production and hitting an invariant that developers only see as a code number; CI/e2e environments running prod builds; trying to read prod error output without the errors table.

Related errors

AI-assisted analysis of mobxjs/mobx@01211a698b (2026-08-28). Data as JSON: /api/errors/c5aaf0e1654bc6f9. Report an issue: GitHub.