agilgur5 / agilgur5/trim-canvas

ESM entry alongside the existing UMD build

Aperta
#11 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub
Lingua principale
JavaScript
Stelle
74
Fork
5
Metriche di merge delle PR
Nessuna PR unita negli ultimi 30g

Descrizione

I realize this package is approaching 9 years since it was last published, but any chance an ESM entry could be added to package.json? The package already ships an ES module file (`index.es6`), so this is mostly a matter of renaming or copying it to `index.mjs` and pointing an `exports` map at it, no source changes needed.

The motivation: `react-signature-canvas` has a proper [`module` and `exports` listing](https://github.com/agilgur5/react-signature-canvas/blob/f6c0b64cf3416681ba959cdaa4eaf2cb4dd87c5e/package.json#L7-L12), so modern bundlers handle it cleanly. The interop fails one layer down on `trim-canvas`, with a runtime "...is not a function" the first time the wrapped function is called. A proper ESM entry would let bundlers consume `trim-canvas` as ESM directly and skip the CJS/ESM interop layer that's currently misbehaving on the published UMD bundle due to:

1. `module.exports = t()` is buried inside an IIFE behind a ternary, so no top-level CJS export is statically visible.
2. `Object.defineProperty(t, "__esModule", { value: true })` is set at runtime inside the inner factory. Interop layers only honor `__esModule` when it's set statically at the top of the file.

Thanks for your consideration.

Guida per i contributori

Nessuna guida per i contributori indicizzata per questo repository

Valutazione

Questa issue non è ancora stata valutata.

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.