@jimmydc/package-example-library-webpack

This is an example project using a minimal setup to achieve a ESM tree-shakeable package by Webpack or other bundlers. It's using native Node functionality (currently on Node 14.15.1 LTS)

• You need to create a namespace (organization) on npm to publish a scoped package.
• The first publish will need public access enabled for scoped packages (e.g. npm publish --access public).
• Using the npm version command will increase the version and make a tagged commit automatically (e.g. npm version patch).
• After installing the package, if the version is below 1.0.0, reinstalling the package will not automatically update the version like the normal npm install behavior. For example, if the package was installed as 0.1.0 (due to it being in a state where every new version could be a breaking change), and a new version 0.2.0 is released, that version will not be installed when running npm update or npm i @jimmydc/package-example-library-minimal. Whoever is installing the package will need to append @latest to the package name. (e.g. `npm i @jimmydc/package-example-library-minimal@latest).
• "sideEffects": false field is required for module level tree-shaking by bundlers like Webpack. It is stating that this library has no side effects, but an array of files with side effects can be used if those exist in your library.
• "type": "module" field is only required for running locally. Project importing this library don't seem to care if it's there or not.
• The exported modules can be imported using commonjs or ESM imports.
• Having an export default in the root does not seem to be a good practice in general. If you ever import that default, it will import the entire library and Webpack cannot tree-shake it away. Even if your library's default export is a simple string, and that is the only thing a user of your library imports into their project, they will get the entire library in their bundle. It seems better to just let the user do import * as whatever as a way of importing everything, because that can be tree-shook. This seems to be best practice now for big packages like React as well. (i.e. DO: import * as React from 'react'; DO NOT: import React from 'react').

Known Issues

• Source maps not properly loading from unpkg.com