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

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.

Start in package.json and compare the ./getPolyfill export with the shipped polyfill.js and the require path in index.js. Reproduce the failure with the provided Node import command, then verify that the chosen export convention resolves successfully from the package and remains consistent with the published file list.