Replace all lodash.* packages

[SukkaW]

The PR replaces all lodash.* packages.

• lodash.escape -> html-escaper
• lodash.flatten -> a modified version of arr-flatten
• lodash.debounce -> debounce
• lodash.pullall -> Array.prototype.filter
• lodash.uniqby -> Set + Array.prototype.filter
• lodash.invokemap -> Object.values

---

Comparison

Running npm i --omit=dev --omit=optional against webpack-contrib/webpack-bundle-analyzer:master:

Running npm i --omit=dev --omit=optional against sukkaw/webpack-bundle-analyzer:repalce-lodash-usage:

The installation size becomes even smaller!

[stof]

For throttle and debounce, I'm using https://www.npmjs.com/package/@github/mini-throttle personally. It is small, efficient and maintained.

[SukkaW]

For throttle and debounce, I'm using https://www.npmjs.com/package/@github/mini-throttle personally. It is small, efficient and maintained.

I was thinking about using perfect-debounce from the unjs community (https://www.npmjs.com/package/perfect-debounce). However, webpack-bundle-analyzer still targets Node.js 10.13.0+ and I was afraid of breaking it. So I chose the debounce package instead. Once the Node.js 10 support has been dropped, we can switch to a more modern package.

[stof]

Do you also want to replace the packages used as dev dependencies ?

[valscion]

Do you also want to replace the packages used as dev dependencies ?

Hmm, I don't know about that. If we do decide to go that route, let's at least split that work to its own PR to make this diff smaller.

[valscion]

This looks good to me!

Any changes you want to add or is this ready to go?

EDIT: Oh right, I forgot about that packageManager comment I had pending. That would need to be resolved first.

[valscion]

Hmm if I've understood the corepack docs correctly, having a packageManager with npm in it is of no use.

Is this needed for some purpose other than that?

[SukkaW]

@valscion

By default npm is already shipped with Node.js, so you don't need corepack to install npm, that's why the docs said something of "no use". But, the field still helps when corepack is enabled and a specific version of npm is needed.

I have been using the latest version of npm (which uses the lockfile v2/v3) for a while. However, the webpack-bundle-analyzer still uses the v1 version of package-lock.json and I need to use an older version of npm.

[valscion]

Okay cool! I didn't know that this allowed corepack to use an older version of npm. This is useful!

[stof]

based on https://nodejs.org/api/corepack.html#how-does-corepack-interact-with-npm, I don't think corepack will install an older npm version

[SukkaW]

based on https://nodejs.org/api/corepack.html#how-does-corepack-interact-with-npm, I don't think corepack will install an older npm version

But for some reason, it does work for me though. I am able to use the 6.x version of npm to generate the correct package-lock.json that won't bloat the change.

And if I cd into other projects the npm automatically reverted back to the latest version.

[SukkaW]

@stof I might have found out why corepack works for me. It might have something to do with my special setup:

• I use fnm, a tool like nvm, to manage my Node.js versions
• Though not recommended, I've manually specified NPM_CONFIG_PREFIX so npm will install global packages to my specific location (instead of the default location)
• I've upgraded my npm version with npm i npm -g, so my npm is located inside NPM_CONFIG_PREFIX instead of the default location.
• In my $PATH, I add the Node.js path before the NPM_CONFIG_PREFIX, so the shell will choose npm from corepack when available.

[valscion]

Okay, so a special setup is the reason.

I don't think having the packageManager line hurts in any way, though. Or do you think it's a bad idea to have in the repository?

[SukkaW]

Okay, so a special setup is the reason.

I don't think having the packageManager line hurts in any way, though. Or do you think it's a bad idea to have in the repository?

Yes, it doesn't hurt.

This packageManager field has no effect on the package's users. Maintainers/contributors who don't have corepack won't be affected either. Maintainers/contributors who have enabled corepack without a specific setup will have an extra copy of corepack's npm installed, it just won't be chosen by the shell (The shell will prefer the original npm without the setup).

[valscion]

Released in v4.10.0! ☺️