dist/less.js (browser build) is UMD but since 4.6.0 treated as ESM due to "type": "module" – breaks bundlers

[dominikschreiber]

To reproduce:

This is not a Less language issue but a packaging issue with dist/less.js. Minimal reproduction:

mkdir repro && cd repro && npm init -y
npm install less@4.6.4 esbuild@0.27.7

src/index.js:

import less from 'less';
console.log(less.version);

npx esbuild src/index.js --bundle --platform=browser --format=esm --outfile=out.js

Current behavior:

Since 4.6.0 (#4411), the less package declares "type": "module" and has an exports map with a "browser" condition pointing to ./dist/less.js:

{
  "type": "module",
  "exports": {
    ".": {
      "browser": "./dist/less.js"
    }
  }
}

But dist/less.js is a UMD bundle that assigns module.exports:

(function (global, factory) {
    typeof exports === 'object' && typeof module !== 'undefined' ? module.exports = factory() :
    typeof define === 'function' && define.amd ? define(factory) :
    (global = typeof globalThis !== 'undefined' ? globalThis : global || self, global.less = factory());
})(this, (function () { 'use strict';
    // ...
}));

esbuild resolves dist/less.js via the "browser" export condition. Because the package has "type": "module", esbuild treats this file as ESM. Since the file has no export default, the default import yields undefined.

With less 4.5.x (no "type": "module", no exports map), esbuild treated dist/less.js as CJS and synthesized a default export automatically — the same build worked fine.

Our workaround is an esbuild plugin that wraps the UMD content in a CJS shim:

plugins: [{
  name: 'less-esm-compat',
  setup(build) {
    build.onResolve({filter: /^less$/}, () => ({
      path: lessDistPath,
      namespace: 'less-esm-compat',
    }));
    build.onLoad({filter: /.*/, namespace: 'less-esm-compat'}, async () => ({
      contents: `var module = {exports: {}}, exports = module.exports;\n${await readFile(lessDistPath, 'utf8')}\nexport default module.exports;`,
      resolveDir: '.',
    }));
  }
}]

Expected behavior:

The browser entry point should either:

1. Be an actual ESM file with export default (preferred), or
2. Use a .cjs extension so it is not subject to the "type": "module" interpretation, or
3. Be explicitly marked as require in the exports map so bundlers apply CJS→ESM interop

Environment information:

• less version: 4.6.0+ (tested with 4.6.4)
• nodejs version: 22.x
• operating system: macOS (not OS-specific)

This is a different issue from #4438 but both are regressions introduced with the 4.6 packaging changes. In our case the Node build (using --platform=node --packages=external) works fine — it's only the browser bundle path that is affected by the UMD/ESM mismatch.

[dosubot]

Hi @dominikschreiber! I'm Dosu and I’m helping the less.js team.

This is indeed a valid packaging issue. The dist/less.js file is confirmed to be UMD format [1], and the Rollup config explicitly outputs it as UMD [2]. Combined with "type": "module" in package.json, bundlers like esbuild that respect the .js extension + package type will treat it as ESM and fail to synthesize a default export.

For context, a closely related regression was already reported and fixed in v4.6.3 via PR #4425 [3] — that fix added the conditional exports map you're seeing now ("browser": "./dist/less.js"). However, that fix resolved the resolution problem (webpack/Vite couldn't find the browser bundle at all) but didn't address this interpretation problem: once the file is resolved, esbuild still treats it as ESM because the package declares "type": "module" and the file has a .js extension.

Your suggested fixes are all reasonable. The cleanest options would be:

1. Rename to dist/less.cjs (or add a sibling .cjs copy) and update the exports map to point to it — this explicitly opts out of the "type": "module" interpretation.
2. Build a true ESM browser bundle (export default ...) alongside or replacing the UMD one, and point the "browser" condition to that.
3. Split the browser condition in the exports map into "browser": { "import": "./dist/less.mjs", "require": "./dist/less.cjs" } similar to how the Node entry is already split.

The current workaround you've shared (wrapping in a CJS shim) is a solid interim solution.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.