No longer maintained per method packages of `lodash` used as dependencies of our dependencies?

[joshtrichards]

With the caveat that this is not my area of expertise so I basically have no real idea what I'm talking about...

lodash deprecated the use of per method packages a long time ago:

• https://github.com/lodash/lodash/issues/3838
• https://lodash.com/per-method-packages
• https://github.com/lodash/lodash/issues/5809#issuecomment-1917546087

As a result, they have been abandoned and have not received the same security updates and fixes as lodash / lodash-es

It appears we have various dependencies that depend on these per method packages. As a result we may be bringing along unmaintained versions of these lodash per method packages, even though we've updated the main lodash package.

Example

While this looks fine:

https://github.com/nextcloud-libraries/nextcloud-axios/blob/b545847cc0e216bf773a0ff979f7d940d6fe878a/package-lock.json#L6197-L6201

These look like dead packages (and there are other similar examples in some of our other libraries):

https://github.com/nextcloud-libraries/nextcloud-axios/blob/b545847cc0e216bf773a0ff979f7d940d6fe878a/package-lock.json#L6203-L6221

Most - all I think - of these are the result of dependencies that depend on these per method modules of lodash.

Since this isn't about overriding versions, but about wanting to change the dependency of our dependencies, what are our options here?

I'm not sure how this gets handled since this is not my aware of expertise at all (also means I may be misunderstanding how dependencies are being managed).

P.S. This came up while researching nextcloud/server#43894

[susnux]

We only can fix this in the using app by defining alias for the module resolution, BUT this might introduce nasty issues.

So the best way is to tell this upstream on the dependencies that they need to migrate.