mismatch between type: "module" and UMD exports.browser mapping

[ro0gr]

When importing jquery-param using ES Module default import syntax (e.g. import param from 'jquery-param'), the resolved import is undefined in environments that prioritize the "browser" package resolution condition (such as Webpack 5, Rollup, or ESM loaders resolving the browser target).

The last Working Version is 1.2.4 (before "type": "module" and "exports" mapping were introduced).

Root Cause

In package.json, "type": "module" is configured, which mandates that ES Module loaders treat all .js files in the package as ES Modules. However, the "browser" key in the "exports" map resolves to ./jquery-param.min.js, which is compiled as a UMD (CommonJS/AMD/Global) module and contains no
ES export statements:

"exports": {
  ".": {
    "import": "./dist/esm/jquery-param.mjs",
    "require": "./dist/umd/jquery-param.js",
    "browser": "./jquery-param.min.js"
  }
}

When a browser-targeted resolver resolves the "browser" key and parses ./jquery-param.min.js as an ES Module, it finds no export default statement. The module resolves to an empty namespace object ([Module: null prototype] {}), resulting in default being undefined.

Solution / Recommendation

Either:

1. Update the "browser" export target to point to an ESM bundle (e.g. ./dist/esm/jquery-param.js or a minified ESM version of the script).
2. Or change the extension of jquery-param.min.js to .cjs (and update the "browser" configuration key accordingly) so that Webpack and Node.js loaders
   recognize it as a CommonJS module and apply default import interop rules correctly.

Reproduction

A minimal reproduction repository running on pure Node.js (with zero bundler overhead) is available here: https://github.com/ro0gr/jquery-param-esm-repro

[knowledgecode]

Hi @ro0gr — thank you for the detailed report and the reproduction repository, both made the root cause immediately clear.

You're right about the cause. The "browser" condition resolved to jquery-param.min.js, which is a UMD bundle kept intentionally for legacy environment compatibility and cannot be changed to ESM. That made either of your proposed solutions impractical in this case.

Instead, the fix in PR #39 (v1.2.9) simply removes the "browser" condition from the exports map. The "import" and "require" conditions are sufficient for all standard modern resolvers, and dropping "browser" eliminates the ambiguity entirely.

I'll close this issue once the PR is merged and v1.2.9 is published. Please feel free to reopen if the problem persists.