Turns out it was something really obvious: you had to use the --allowJs option. This worked for me:

tsc --moduleResolution "node" --module "commonjs"  --allowJs main.ts

Though, I still can't figure out why d3 worked while the others libraries didn't.

Is this a bug? Kind of.

The error message is indeed confusing and misleading—you’re correct that there is no runtime representation of an import type statement, so the fact that the error message says it will become a require call and suggests writing a dynamic import is a bug. However, this code is intended to have an error. In TypeScript 5.7, the error message was updated to say

Type-only import of an ECMAScript module from a CommonJS module must have a 'resolution-mode' attribute.

...which doesn’t answer the question of why the import is an error, which I’ll come back to, but it does answer your next question:

Is there a workaround? Yes!

Since TypeScript 5.3, the error can be silenced by adding a resolution-mode import attribute:

import type { Options } from "./types.ts" with { "resolution-mode": "import" };

or, in type import form:

const options: import("./types.ts", { with: { "resolution-mode": "import" } }) = {};

The resolution-mode import attribute, which is only supported on type-space imports, tells the TypeScript compiler whether to resolve the module specifier like Node.js would resolve a CommonJS require or an ESM import, which use completely separate module resolution algorithms. (In this example, both "require" and "import" would work because the module specifier is a relative path including the file extension. If the module specifier had been "./types", only "require" would work, since the Node.js ESM module resolution algorithm does not support omitting file extensions on relative paths.)

Why is this an error?

Instead of the example with "./types.ts", imagine that the error came from an import of a third-party dependency that ships only ESM code:

// processOptions.cts
import type { Options } from "remark-mdx";

Since the importing file is .cts, this type-only import resolves using the require algorithm, but it resolves to an ES module—remark-mdx does not contain any CommonJS. Now suppose that the authors of remark-mdx decided to begin shipping a CommonJS build alongside the ESM in the package, using package.json conditional "exports". Adding a conditionally loaded legacy build should be a backward compatible change, right? Well, not for the type checking of processOptions.cts. If remark-mdx adds new types that resolve under the require algorithm in a patch bump, that could change the type of Options. But if we explicitly specify with { "resolution-mode": "import" }, we can be pretty sure that our code will be unaffected by remark-mdx’s hypothetical decision to add a CommonJS entrypoint.

This concern is about protecting the ability of external package authors to make backward-compatible changes via package.json "exports". It really doesn’t apply at all to relative imports of your own files that you control. However, it was decided that, for consistency, the error should not be conditional on whether the import module specifier is relative. There is a lot of discussion about this on the TypeScript issue tracker, linked from the PR that changed the error message.

This is a recipe for solving a common problem. We'll try to keep it up-to-date. If it is confusing, we can update it based on questions posted here.

Short Answer

Use export = to build a CommonJS module that exports a function.

The TypeScript docs say:

TypeScript supports export = to model the traditional CommonJS and AMD workflow... The export = syntax specifies a single object that is exported from the module. This can be a class, interface, namespace, function, or enum.

Full Setup

myModule.ts

export = function myModule(name: string): void {
  console.log(`Hello, ${name}!`)
}

tsconfig.json

{
  "compilerOptions": {
    "target": "es5",
    "module": "commonjs"
  }
}

myModule.js (output)

"use strict";
module.exports = function myModule(name) {
    console.log("Hello, " + name + "!");
};

demo.js (usage)

const myModule = require('./my-module');

myModule('Luiz'); // Hello, Luiz!

Yes, you can use it in a same manner that you would use it in Javascript. Typescript is superset of Javascript, all things possible in Javascript are also possible in Typescript.

Refer to this:

https://www.typescriptlang.org/docs/handbook/modules.html

And search (ctrl/cmd + f) for 'require'