Replace all lodash.* packages#612
Conversation
ed911d0 to
609b4d5
Compare
|
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 |
lodash.* packageslodash.* packages
|
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. |
| "engines": { | ||
| "node": ">= 10.13.0" | ||
| }, | ||
| "packageManager": "npm@6.14.8", |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Okay cool! I didn't know that this allowed corepack to use an older version of npm. This is useful!
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
@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 likenvm, to manage my Node.js versions - Though not recommended, I've manually specified
NPM_CONFIG_PREFIXso 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 insideNPM_CONFIG_PREFIXinstead of the default location. - In my
$PATH, I add the Node.js path before theNPM_CONFIG_PREFIX, so the shell will choose npm fromcorepackwhen available.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Okay, so a special setup is the reason.
I don't think having the
packageManagerline 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).
|
Released in v4.10.0! |
The PR replaces all
lodash.*packages.lodash.escape->html-escaperlodash.flatten-> a modified version ofarr-flattenlodash.debounce->debouncelodash.pullall-> Array.prototype.filterlodash.uniqby-> Set + Array.prototype.filterlodash.invokemap-> Object.valuesComparison
Running
npm i --omit=dev --omit=optionalagainstwebpack-contrib/webpack-bundle-analyzer:master:Running
npm i --omit=dev --omit=optionalagainstsukkaw/webpack-bundle-analyzer:repalce-lodash-usage:The installation size becomes even smaller!