Fix: Remove ambiguous extensionless main field

[lcharette]

Problem

The current package.json has an extensionless main field:

"main": "./lib/limax"

When both limax.mjs and limax.cjs exist in the same directory, this creates ambiguity for module bundlers like esbuild (used by Vite's dependency pre-bundler). The extensionless path can cause incorrect module resolution, where the package is interpreted as CommonJS even when imported as ESM. This result in the following error when using Vite dev server:

Importing binding name 'default' cannot be resolved by star export entries

Solution

Remove the main field entirely since the package already properly defines exports with conditional imports:

"exports": {
  "types": "./index.d.ts",
  "import": "./lib/limax.mjs",
  "require": "./lib/limax.cjs"
}

Modern tools (Node.js 12.20+, Webpack 5, Vite, etc.) prioritize exports over main. For legacy tools that don't support exports, Node.js will still resolve the module correctly since "type": "module" is declared.

Impact

• ✅ Removes ambiguity in module resolution
• ✅ Modern bundlers work correctly without requiring special configuration
• ✅ Maintains backward compatibility via exports conditional fields
• ✅ No breaking changes for existing users

---

Alternatively, if maintaining the main field for older tooling is desired, it should include an explicit extension (e.g., "main": "./lib/limax.cjs" or "main": "./lib/limax.mjs").

[lovell]

Brilliant, thank you for fixing this.

[lovell]

v4.2.2 now available.

[lcharette]

FYI, and it doesn't invalidate this PR, but I still get the same error on my project.

The issue occurs because limax.mjs is a pure ES module that imports CommonJS dependencies:

import speakingurl from 'speakingurl';  // CommonJS package
import hepburn from 'hepburn';          // CommonJS package
import { pinyin } from 'pinyin-pro';    // Likely CommonJS

When served directly to the browser without pre-bundling (which happens when the parent package is excluded from Vite's optimizer), browsers cannot handle the CJS/ESM interop. To bypass the issue, I'll add limax to my optimizeDeps.include configuration as a workaround (or pre-bundle my parent package), but this should not be necessary for a packaged ESM module. I'm leaving this here in case it could help someone else.