10

For a JS library which is published in a structure like ...

my-package\
  dist\
    my-package.cjs.js
    my-package.cjs.min.js
    my-package.cjs.min.js.map
    my-package.esm.js
    my-package.esm.min.js
    my-package.esm.min.js.map
    my-package.umd.js
    my-package.umd.min.js
    my-package.umd.min.js.map
  package.json

E.g. built to CJS, ESM, and UMD bundles, each having a "source", minified and map file.

package.json

{ // ...
  "main": "dist/my-package.cjs.js",
  "module": "dist/my-package.esm.js",
  "browser": "dist/my-package.umd.js"
}

My assumption is that these properties should point to the "source" file, and tools used to bundle my library (e.g. Webpack) into an external project are smart enough to choose the minified file if the build is non-debug/non-dev mode.

Or, am I wrong and these properties should point to the minified file?

Josh M.
  • 26,437
  • 24
  • 119
  • 200

1 Answers1

-2

I think you are right. If you are only releasing, for example, ESM and UMD, you could then stick to

{ // ...
  "main": "dist/my-package.umd.js",
  "module": "dist/my-package.esm.js"
}

The most important thing is that, using "module", you can provide a version of your bundle that is efficiently consumed by an app that is compiled through Webpack or Rollup. Tree shaking can be applied in that case so all the dead code is not included in the final bundle.

This is useful, for example, for a React components library. You can export it this way so the apps that use it only get the code for the components being consumed.

This was answered before here:

What is the "module" package.json field for?

rmartrenado
  • 1,516
  • 1
  • 18
  • 42