This is an anti-pattern. When you include a package this way, it cannot be de-duped across different projects. It results in this mess:

These packages are deprecated and will no longer be supported as of lodash v5.
https://github.com/lodash/lodash/wiki/Roadmap
Instead, you should be depending on the main library, but importing individual packages, e.g.
const find = require('lodash/find');
There is a Babel plugin that does this for you,
https://github.com/lodash/babel-plugin-lodash
However, seeing that you are using ts, unless there is a ts equivalent, you'd need to code all the references by hand.
If you are going to go this way, please add a suggestion for the consumers to also use https://github.com/lodash/lodash-webpack-plugin to further decrease bundle size.
@gajus We do want to move away from using the individual lodash pacakges, but ideally without introducing another build step.
We have dropped the entire Apollo stack from product more or less because of the above screenshot. A simple query mechanism with in-built state management should not weight half of the application. I'd say therefore it is an important issue (and the entire bundle size in general).
However, this was only one of the reasons. The other being poor integration with immutable.js and very hacky integration with isomorphic rendering tools.
I think that
import merge from 'lodash/merge';
instead of
import merge from 'lodash.merge';
is a good start
@seeden Yeah, I think that's a good star. I would definitely merge it if you made a PR. I can also do it myself, but I don't think I would get to it this week.
@helfer I created PR #997
Most helpful comment
I think that
instead of
is a good start