I got a good inspiration.

[lemanschik]

Some how the issue triggered my mind and i found out that it would be the most clever to code a total new build tool that
translates package.json into a esm-package.js as also or package.js convention and then let all calls to require get handled
as would they export module and not module.exports

• Create doc on how to support ESM and CommonJS when publishing modules nodejs/package-maintenance#542
• The main inspiration was the comment from the other well known NodeJS Contributor in the above issue
  • Everything should be something and he is right it should be a Module that was the miss conception of require.

Conclusion visual

Real ESM most less code

import()
export {}

The real source code how it shoud be to be analyze able and used

const moduleName = {}; // () => {}
const exports = moduleName;
export { exports, default: exports } // ES Export 
export { default: exports } // can be translated via ESModuleInterOP to NodeJS Interop Pattern syntacticDefaultImport
// Correct CJS Source module that is compatible with NodeJS InterOp Style
module.exports = { exports }
// Correct ESModule transpiled from CJS  Source module that is compatible with NodeJS InterOp Style
module.exports = { default: exports } // can be translated via ESModuleInterOP to NodeJS Interop Pattern syntacticDefaultImport

NodeJS then only applys compat like and calls that Module InterOp Node! so Module is the InterOp system and not all others are the InterOp System of Node! inverse of control

const { exports: moduleName } = require('module');
const { exports: moduleName } = await import('module');
// NodeJS InterOP Module mode only valid for nodejs not for anything else in ECMAScript universe.
module.exports = moduleName

NodeJS View Of the Real world then.

const { exports: moduleName } = require('module');
const { exports: moduleName } = await import('module');
const { default: moduleName } = await import('module');
const { moduleName } = await import('module'); // can come from default or exports 

maybe some how allow to build only pure functions we can detect sideEffects already.

Deep technical explaination

A Function gets executed by a Engine while a Module Resolution can be by design done anywhere else but triggered by the engine so to resolve require calls we need to emulate the engine thats why we in bundlers like rolllup need to do massiv ast parsing when evaluating the results

everything in ECMAScript is a Object so to be a Readable object you can not be the result of a Function execution like it would be the case if module.exports = function is done so simply shifting that to export a module with a exports property fixes the need to emulate the engine as the result of module resolution does not depend anymore on the exection engine like it would be the case with the current concept.

the conclusion is clear at present many project mentioned in the above linked package maintainance discussion ship the engine to solve the problem. All this would end. we can simply from then on start automated wrapping cjs into scopes { } and this way simulate use strict we execute the code as it would be ESM when it breaks we warn that the code needs upgrades like cycle dependencie cases and such.

Edge cases

• depending on __dirname __filename and other globals as also path and fs methods not universal uri methods.
• incompatbile WHATWG new URL() and node:url eg: URL.parse()

[frank-dspeed]

This will maybe get usefull for a loader later need to check how it plays out with indipendent doc implementations as globalThis and then call it a day i simply run each module on its own context and do not even care if that then does not run it will error and tell us

which other hoax the coder did like cyclic deps and so on