Hello 馃憢
today, this package has multiple copies/entries in it:
dist/diff.js - a UMD bundle
- Only exposed under
package.json#browser and package.json#unpkg keys
- Suggests this is the browser bundle
dist/diff.min.js - the same UMD bundle minifiedlibjs/ - a CommonJS entry point
- Includes types
- Includes sourcemaps
libesm/ - an ES module entry point
- Includes types
- Includes sourcemaps
Times have changed a bunch since this package was created. We're now in a situation where:
- All browsers support ES modules
- All runtimes (e.g. Node, Bun, etc.) support ES modules
- CommonJS projects in Node can
require(esm) an ES module
- Most web projects today are using a bundler
So it seems there's opportunity here for a new major one day which dumbs this down to:
dist/ - an ES module entry point
- Includes types
- Includes sourcemaps
would love to hear your thoughts on this @kpdecker 馃檹
an extra win from this could also be to stop shipping sourcemaps (which account for a large % of the tarball size we pull from npm). The code is already readable, unminified, and has type definitions. So we're not gaining much from shipping them.
Hello 馃憢
today, this package has multiple copies/entries in it:
dist/diff.js- a UMD bundlepackage.json#browserandpackage.json#unpkgkeysdist/diff.min.js- the same UMD bundle minifiedlibjs/- a CommonJS entry pointlibesm/- an ES module entry pointTimes have changed a bunch since this package was created. We're now in a situation where:
require(esm)an ES moduleSo it seems there's opportunity here for a new major one day which dumbs this down to:
dist/- an ES module entry pointwould love to hear your thoughts on this @kpdecker 馃檹
an extra win from this could also be to stop shipping sourcemaps (which account for a large % of the tarball size we pull from npm). The code is already readable, unminified, and has type definitions. So we're not gaining much from shipping them.