lodash almost gone

[jimmywarting]

There are 3 remaining files after this gets merged.

They are slightly more annoying and harder to refactor out cuz of things like Lodash 'where' clause in _.get for example.
i would have use optional chaining...

Will leave the rest to you to decide what to do with it:

• packages/inquirer/lib/ui/prompt.js
• packages/inquirer/lib/prompts/base.js
• packages/inquirer/lib/objects/choices.js
• npm uninstall lodash (from all packages)

[codecov]

Codecov Report

Merging #1069 (328a021) into master (32854c0) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1069   +/-   ##
=======================================
  Coverage   88.30%   88.30%           
=======================================
  Files           4        4           
  Lines         171      171           
  Branches       23       23           
=======================================
  Hits          151      151           
  Misses          1        1           
  Partials       19       19           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 32854c0...328a021. Read the comment docs.

[SBoudrias]

Ah yeah, that get/set in the prompt file will be hard to re-implement... I'd keep those there for simplicity; the new version (if it ever gets to stable 😅) would get rid of this since it's standalone prompt packages.

I think the other instances can be replaced with similar logic. Not sure the _.isPlainObject checks are really necessary; truthy/simple type check could be enough.

[jimmywarting]

Not sure the _.isPlainObject checks are really necessary; truthy/simple type check could be enough.

Yep, thought about it too. but wasn't 100% sure what gets passed in there. I'm new to this project...
back in my mind it goes: "hmm, 🤔 they must have some very specific reason to use a more adv isPlainObject and not just using a simple thrutly, typeof x === 'object' or _.isObject better not to touch it then". Null is an object after all...

https://github.com/SBoudrias/Inquirer.js/search?q=lodash

[jimmywarting]

also here is a crazy idea while doing all this work, i found this:

Inquirer.js/packages/inquirer/lib/objects/choices.js

Lines 94 to 122 in 3a796d8

	// Expose usual Array methods
	indexOf(...args) {
	return this.choices.indexOf(...args);
	}
	forEach(...args) {
	return this.choices.forEach(...args);
	}
	filter(...args) {
	return this.choices.filter(...args);
	}
	reduce(...args) {
	return this.choices.reduce(...args);
	}
	find(func) {
	return this.choices.find(func);
	}
	push(...args) {
	const objs = args.map((val) => new Choice(val));
	this.choices.push(...objs);
	this.realChoices = this.choices
	.filter(Separator.exclude)
	.filter((item) => !item.disabled);
	return this.choices;
	}

Why not just go with:

class Choices extends Array {
  push(...args) {
    super.push(...args.map((val) => new Choice(val))
  }
}

Then you can have all array methods (iterators, .at(), .values(), .entries()) and so on :P
totally okey now when we have class/extend

[SBoudrias]

Ah yes, that was initially implemented before we were able to extend native classes (and even before class keyword 😅 ).

For the isPlainObject check, pretty sure it was used because of how unreliable typeof foo === 'object' is. Obv this code was written a long time ago, so I could've forgotten some specific cases calling for isPlainObject vs isObject... But I think the UTs would catch blatant error that could cause.