exports "./getPolyfill" points at getPolyfill.js, but the package ships polyfill.js

package.json から始め、./getPolyfill の export を同梱されている polyfill.js および index.js の require パスと比較します。提供されている Node の import コマンドで失敗を再現し、選択した export 規約によって package から正常に解決され、公開されているファイル一覧との一貫性が保たれることを確認します。

The problem

package.json maps "./getPolyfill" to "./getPolyfill.js", and the package ships polyfill.js. There is no getPolyfill.js, on main or in the published tarball, so that subpath cannot be imported.

Reproduce

npm i string.prototype.repeat@1.0.0
node --input-type=module -e "await import('string.prototype.repeat/getPolyfill')"

ERR_MODULE_NOT_FOUND: Cannot find module '.../string.prototype.repeat/getPolyfill.js'

Details

"exports": {
  ".": "./index.js",
  "./auto": "./auto.js",
  "./shim": "./shim.js",
  "./getPolyfill": "./getPolyfill.js",   <- no such file
  "./implementation": "./implementation.js",
  "./package.json": "./package.json"
}

Contents of the published 1.0.0 tarball: LICENSE-MIT.txt, README.md, auto.js, implementation.js, index.js, package.json, polyfill.js, shim.js, tests/.

The other four subpaths all resolve; this is the only one that does not.

Node performs no extension or name search on an exports target — it is taken exactly as written — so nothing falls back to polyfill.js.

Two ways to fix it, and which one you want depends on the convention you'd rather keep:

• point the mapping at the file that exists — "./getPolyfill": "./polyfill.js", or
• rename polyfill.js to getPolyfill.js, which is what the sibling es-shims packages call it and what index.js would then require.

Happy to open a PR for whichever you prefer.

Notes

Found by an automated checker I'm building that compares a manifest's declared entry points against the files a package actually ships. I verified this one by hand against the published 1.0.0 tarball and against main before filing.