TypeScript type errors when using `moduleResolution: "Node10"` or `"Node"` in tsconfig

[yamcodes]

TypeScript type checking fails when tsconfig.json uses moduleResolution: "Node10" or "Node". This also occurs when moduleResolution is unspecified and module is "commonjs", as TypeScript defaults to "Node10" in that case.

Root cause:
The older "Node10" and "Node" module resolution strategies don't properly support the package.json exports field, causing type resolution failures.

Affected scenarios:

• type() function returns any instead of preserving types
• Direct string type references like "string.url" cause TypeScript errors
• Type resolution fails when using CommonJS with default module resolution

Example:

// tsconfig.json - ❌ Causes type errors
{
  "compilerOptions": {
    "module": "commonjs"
    // moduleResolution defaults to "Node10" when unspecified
  }
}

// Also fails with explicit Node10/Node:
{
  "compilerOptions": {
    "module": "commonjs",
    "moduleResolution": "Node10" // ❌ Causes type errors
  }
}

// ✅ Recommended fix: Use modern module resolution
{
  "compilerOptions": {
    "module": "commonjs",
    "moduleResolution": "node16" // or "nodenext"
  }
}

Impact:

• Users with CommonJS projects using default or older module resolution cannot use arkenv with proper type checking
• Forces workarounds or switching to modern module resolution strategies

Solution:
Updated package.json exports to properly specify types for both ESM and CommonJS conditions. For best results, use moduleResolution: "node16" or "nodenext" as these fully support the exports field.

References:

• TypeScript moduleResolution documentation

Related issues:

• Question: How to type URLs? #374 is most likely caused by this.
• Fix type() function returning any instead of preserving types #375 - Fix type() function returning any instead of preserving types
• Bun-specific TypeScript error with string.url submodule reference #376 - Bun-specific TypeScript error with string.url submodule reference