In the document Authoring libraries, it's mentioned to install lodash as a devDependency, since we don't want to bundle it together. Also, it's suggested to list it as a peerDependency and put it in the external option. I believe this is a misguidance.
Firstly, if lodash is used within a library, there would be require('lodash') or import from 'lodash' statements, which clearly indicate a direct dependency. Therefore, it should be listed in dependencies.
If users use a bundler to package their own applications, once your library is installed, lodash will also be installed and can be deduplicated with the lodash versions depended on by other libraries used by users. In this case, all you need to do is put ALL dependencies into the external option.
If users are importing your library through a script tag, bundling utility libraries like lodash isn't necessarily a bad practice.
Regardless, lodash should never be listed as a peerDependency or a devDependency.
In the document Authoring libraries, it's mentioned to install
lodashas a devDependency, since we don't want to bundle it together. Also, it's suggested to list it as apeerDependencyand put it in theexternaloption. I believe this is a misguidance.Firstly, if
lodashis used within a library, there would berequire('lodash')orimport from 'lodash'statements, which clearly indicate a direct dependency. Therefore, it should be listed in dependencies.If users use a bundler to package their own applications, once your library is installed,
lodashwill also be installed and can be deduplicated with thelodashversions depended on by other libraries used by users. In this case, all you need to do is put ALL dependencies into theexternaloption.If users are importing your library through a script tag, bundling utility libraries like
lodashisn't necessarily a bad practice.Regardless,
lodashshould never be listed as apeerDependencyor adevDependency.