When it comes to deciding on including dependencies in your project, it's essential to weigh the pros and cons. For instance, React can only exist in one version within a project, so it's generally advised not to include it. Instead, dependencies that are necessary but not bundled should be listed as peerDependencies in your package.json, leaving the responsibility of downloading them to the consumer.
While including dependencies as dependencies ensures automatic download by the consumer, it may lead to a larger bundle size than necessary. Considering the end-users and the intended usage of the package is crucial when making this decision. It's generally better to refrain from adding unnecessary dependencies to keep the resulting bundle size small. However, there are cases where including certain dependencies may be necessary, especially if there's a likelihood that they are not available in the consumer's build environment.
Take, for example, the scenario of using Material-UI within an organization. Including Material-UI components in a package meant for internal use within the organization may not be ideal, as Material-UI is expected to be present in all projects. This decision places the onus on the consumers to ensure alignment with the appropriate version of Material-UI in each project. On the other hand, including Material-UI in the package could be more suitable for a different consumption context.
In my opinion, bundling your package can complicate the process of tree shaking for the consumer, especially in the case of esm packages where bundling is not recommended. On the flip side, bundling is detrimental in cjs packages, as it hinders the consumer from making specific imports to avoid importing unnecessary code.