Restore webpack/browser compatibility for import less from "less" in 4.6.x

[Copilot]

LESS 4.6.2 introduced a packaging/export regression that made webpack browser builds resolve the Node entry path and fail on core-module resolution (module). This PR restores browser-safe resolution while preserving Node ESM/CJS import behavior.

• Export map routing

  • Routes browser consumers of the package root to the UMD browser bundle.
  • Keeps Node import/require paths explicit and stable.

  {
    "exports": {
      ".": {
        "browser": "./dist/less.js",
        "import": "./lib/less-node/index.js",
        "require": "./dist/less-node.cjs",
        "default": "./lib/less-node/index.js"
      }
    }
  }

• CJS bundle hardening

  • Builds a dedicated dist/less-node.cjs artifact for require("less").
  • Shims module.createRequire in the rollup pipeline and inlines package version to avoid runtime path-dependent package.json lookups from bundled output.

• Regression coverage for import patterns

  • Adds focused export/import compatibility checks for:
    • Node ESM (import less from "less")
    • Node CJS (require("less"))
    • webpack browser target (import less from "less" resolving to dist/less.js)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>LESS 4.6.2 causing build error</issue_title>
<issue_description>To reproduce:
npm i with LESS set to ^4.5.1 or 4.6.2
running build with webpack

Current behavior:
webpack unable to build frontend applicaiton due to the following error
Module not found: Error: Can't resolve 'module' in 'C:\Users\xxx\git\xxx\node_modules\less\lib\less-node'

Expected behavior:
webpack builds normally

Environment information:

• less version: 4.6.2
• nodejs version: v24.0.0
• operating system: windows & linux debian (when building in server)
• webpack: 5.64.6

Able to resolve when locking LESS to 4.5.1 in package.json
</issue_description>

<agent_instructions>debug it and fix it</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@matthew-dean My fault! Let me try to address right away. It was not intended to be a breaking change. I added tests for both ESM and CJS imports but maybe I missed some of these patterns? @matthew-dean @alexander-akait That's generally not true on modern Node.

Current Node docs explicitly say require() can load ECMAScript modules from CommonJS as long as the ESM graph is synchronous, meaning no top-level await. Node also documents support for loading ES modules using require(), with a flag to disable it if needed.

It's also not true that there will inevitably be issue with caches and memory leaking.

But, that said, obviously there still is a loading problem, which I will address today.</comment_new>
<comment_new>@matthew-dean
@isgeoffrey @lincolnkjy @alexander-akait Can I get you to try less@4.6.3-beta.0 ?</comment_new>
<comment_new>@matthew-dean
@alexander-akait Thanks! Sorry for the inconvenience. Has more test coverage around each scenario now with a specific webpack test harness.

I'm going to go ahead and publish, but the changes are here if anyone finds something that looks problematic.</comment_new>
<comment_new>@matthew-dean
Leaving open in case someone else experiences any issues. Will close later.</comment_new>

• Fixes LESS 4.6.2 causing build error #4423

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[matthew-dean]

@copilot This should be fixed now, yes? In 4.6.3?

[Copilot]

@copilot This should be fixed now, yes? In 4.6.3?

Yes — this is fixed in 4.6.3. The export map and CJS bundle changes in 6cafcc0 are the fix, and the focused regression checks (test/exports/import-patterns.cjs and test/exports/webpack-browser.cjs) pass against that version.