A pull request by @JakobJingleheimer was merged and maintainers requested a documentation change.

See pull request: webpack/webpack#14998

In order for Node.js to detect named exports in CJS, they must be statically available. However, without this change, webpack does not produce exports that way—webpack will respect source code that is originally written in such a way, but it won't itself produce it (ex if the source code is ESM).

The outputted code will now look like:

// …

function test() {} // user code

module.exports.test = test // this is the change

And when imported into an ESM file:

import * as cjs from './output.cjs';
import { test } from './output.cjs';

console.log(cjs);
/*
[Module: null prototype] {
  __esModule: true,
  default: { test: [Function: test] },
  test: [Function: test]
}
*/

console.log(test)l
/*
[Function: test]
*/

What kind of change does this PR introduce?

Enhancement

Did you add tests for your changes?

Will do once approach etc are confirmed.

Does this PR introduce a breaking change?

No: It requires the user to opt-in via configuration flag. Also, Node.js still automatically adds the named exports to default anyway (in addition to exposing them as named exports).

What needs to be documented once your changes are merged?

New output.library.type option commonjs-static which is similar to commonjs-module but emits code in a statically analyse-able way, so Node.js is able to construct named exports in it's commonjs esm compat layer.
Exports must be statically known to webpack for this to work. optimization.providedExports must not be disabled.