docs: add instructions to support moduleResolution: node

Author: satya164

docs/pages/esm.md

@@ -82,25 +82,7 @@ To configure a dual package setup, you can follow these steps:
    }
    ```
 
-2. Optionally change the `main` field in your `package.json` to point to the CommonJS build:
-
-   ```diff
-   - "main": "./lib/module/index.js",
-   + "main": "./lib/commonjs/index.js",
-   ```
-
-   This is needed if you want to support tools that don't support the `exports` field and need to use the CommonJS build.
-
-3. Optionally add a `module` field in your `package.json` to point to the ESM build:
-
-   ```diff
-     "main": "./lib/commonjs/index.js",
-   + "module": "./lib/module/index.js",
-   ```
-
-   The `module` field is a non-standard field that some tools use to determine the ESM entry point.
-
-4. Change the `exports` field in your `package.json` to include 2 conditions:
+2. Change the `exports` field in your `package.json` to include 2 conditions:
 
    ```diff
    "exports": {
@@ -128,6 +110,57 @@ To configure a dual package setup, you can follow these steps:
 
    The `default` field is the fallback entry point for both conditions. It's used for the actual JS code when the library is imported or required.
 
+3. Optionally change the `main` field in your `package.json` to point to the CommonJS build:
+
+   ```diff
+   - "main": "./lib/module/index.js",
+   + "main": "./lib/commonjs/index.js",
+   ```
+
+   This is needed if you want to support tools that don't support the `exports` field and need to use the CommonJS build.
+
+4. Optionally add a `module` field in your `package.json` to point to the ESM build:
+
+   ```diff
+     "main": "./lib/commonjs/index.js",
+   + "module": "./lib/module/index.js",
+   ```
+
+   The `module` field is a non-standard field that some tools use to determine the ESM entry point.
+
+5. Optionally add a `types` field in your `package.json` to point to the CommonJS type definitions:
+
+   ```diff
+     "main": "./lib/commonjs/index.js",
+     "module": "./lib/module/index.js",
+   + "types": "./lib/typescript/commonjs/src/index.d.ts",
+   ```
+
+   This is necessary to support legacy TypeScript setup, i.e. which have `moduleResolution: "node10"` or `moduleResolution: "node"` under the `compilerOptions` section in the `tsconfig.json`.
+
+Putting it all together, the fields in your `package.json` file should look like this:
+
+```json
+{
+  "main": "./lib/commonjs/index.js",
+  "module": "./lib/module/index.js",
+  "types": "./lib/typescript/commonjs/src/index.d.ts",
+  "exports": {
+    ".": {
+      "import": {
+        "types": "./lib/typescript/module/src/index.d.ts",
+        "default": "./lib/module/index.js"
+      },
+      "require": {
+        "types": "./lib/typescript/commonjs/src/index.d.ts",
+        "default": "./lib/commonjs/index.js"
+      }
+    },
+    "./package.json": "./package.json"
+  }
+}
+```
+
 > **Important:** With this approach, the ESM and CommonJS versions of the package are treated as separate modules by Node.js as they are different files, leading to [potential issues](https://nodejs.org/docs/latest-v19.x/api/packages.html#dual-package-hazard) if the package is both imported and required in the same runtime environment. If the package relies on any state that can cause issues if 2 separate instances are loaded, it's necessary to isolate the state into a separate CommonJS module that can be shared between the ESM and CommonJS builds.
 
 ## Guidelines