I am asking this question after has not been answered to similar one in Stack Overflow despite the fact that I have started the bounty and created the reproduction. Hope this question will be answered here.

Remark

Weird things are happening with modules types is Node.js.
On the one hand, the CommonJS modules are still (for the end of 2024) default in Node.js.
On the other hand, the agitating about migrating to ECMAScript modules is in process.

However, this migration is not simple in usually will not ends by replacing of require() to import and adding of "type": "module" to the package.json. So, because a large number of npm libraries are still CommonJS, installing the various decencies to our project usually we have the mashup of CommonJS modules and ECMAScript modules:

In gulp-imagemin, there is the issue titled 8.0.0 - ESM only? Serious?.
Maybe it is outdated (Aug 2021), but I still facing with ESM incompatibility errors using all Webpack, tsx and ts-node. Well, this question about Webpack, so time to return to the subject of this question.

My Case

I am creating the project building tool, but to build its own source code, the Webpack is being used.

AFAIK:

• The Webpack is partially ignores the tsconfig.json in favor to the Webpack configuration.
  Particularly, the target: "node" affects on which modules will be at the output.
• The usage of webpack-node-externals is de facto required for Node.js because without it the plenty of warning and/or errors will be on trying to use some native and/or npm modules.

So, if to make the previous scheme more detailed, besides the output entry point there are will be the plenty of non-bundled node_modules:

The building of entry point going well, but if to try to execute the built entry point, the error like the following one will be:

D:\IntelliJ IDEA\InHouseDevelopment\Example\MainPackage\EntryPoint.js:14040
module.exports = require("gulp-imagemin");
                 ^

Error [ERR_REQUIRE_ESM]: require() of ES Module D:\IntelliJ IDEA\InHouseDevelopment\Example\MainPackage\node_modules\gulp-imagemin\index.js from D:\IntelliJ IDEA\InHouseDevelopment\Example\MainPackage\EntryPoint.js not supported.
Instead change the require of index.js in D:\IntelliJ IDEA\InHouseDevelopment\Example\MainPackage\EntryPoint.js to a dynamic import() which is available in all CommonJS modules.
    at gulp-imagemin (D:\IntelliJ IDEA\InHouseDevelopment\Example\MainPackage\EntryPoint.js:14040:18)
    at __webpack_require__ (D:\IntelliJ IDEA\InHouseDevelopment\Example\MainPackage\EntryPoint.js:14370:42)
    at ./ProjectBuilding/AssetsProcessing/Images/ImagesProcessor.ts (D:\IntelliJ IDEA\InHouseDevelopment\Example\MainPackage\EntryPoint.js:1093:41)
    at __webpack_require__ (D:\IntelliJ IDEA\InHouseDevelopment\Example\MainPackage\EntryPoint.js:14370:42)
    at ./ProjectBuilder.ts (D:\IntelliJ IDEA\InHouseDevelopment\Example\MainPackage\EntryPoint.js:166:43) {
  code: 'ERR_REQUIRE_ESM'
}

Node.js v22.0.0

Some specific packages.

• The gulp-imagemin is being used directly. From the version 8.0.0 it is the pure ESM.
• The imagemin on which the previous one depends also the ESM since 8.0.0
• Since version 1.0.0, w3c-html-validator is not compatible with my Webpack preset. In the middle of 2024, the error has been caused by the chalk dependency of w3c-html-validator. Currently, with version 1.8.2, w3c-html-validator itself causes the "Error [ERR_REQUIRE_ESM]: require() of ES Module" error.

Reproduction

The reproduction includes the cases with imagemin + imagemin-pngquant and w3c-html-validator.

If you will be so kind to checkout this GitHub repository, all you need to get the above error is execute

node ImageminPngquantTest.js

for imagemin + imagemin-pngquant test, and

node HTMLValidationTest.js 

for the w3c-html-validator. In both cases, you will get the "Error [ERR_REQUIRE_ESM]: require() of ES Module" error.

If you want to correct the source TypeScript code, please execute

npm run build

to rebuild the output JavaScript code.

Running away from the problems

The following measures are the workarounds rather than solution.

Use the dynamic import

Depending on the application, it could cause the large-scale refactoring.
For example, assume that previously the functionality imported synchronously is being used in the classes' constructors. But the class constructor could not be async. Thus, we must do something, for example, split the initialization to 2 steps.

For the Gulp case, most of Gulp task functions (especially the ones which are using the plugins) returns the streams, not promises. Unfortunately, the combining of promises and streams is not simple in the Gulp.

Well, even if above problems are solvable, it was just the example. But generally, the starting of the usage of the dynamic import could cause the large-scale changes in the code.

Set type: module to the package.json

I can not understand hot it could be recommended such simply.

The adding of type: module to "package.json" could and most likely will brake both project and what depends on it!.

So, unfortunately it is not that could be simply done.