@reubenrybnik Thank you for submitting this PR!

This is a live comment which I will keep updated.

Code Reviews

Because you edited one package and updated the tests (👏), I can help you merge this PR once someone else signs off on it.

Status

• ✅ No merge conflicts
• ✅ Continuous integration tests have passed
• ✅ Most recent commit is approved by type definition owners or DT maintainers

All of the items on the list are green. To merge, you need to post a comment including the string "Ready to merge" to bring in your changes.

{
  "type": "info",
  "now": "-",
  "pr_number": 45893,
  "author": "reubenrybnik",
  "owners": [
    "borisyankov",
    "jbaldwin",
    "ccurrens",
    "confususs",
    "jgonggrijp",
    "ffflorian",
    "regevbr",
    "peterblazejewicz",
    "reubenrybnik"
  ],
  "dangerLevel": "ScopedAndTested",
  "headCommitAbbrOid": "d952cf3",
  "headCommitOid": "d952cf3c9669bd2a1b39f465bc3edc514d545609",
  "mergeIsRequested": true,
  "stalenessInDays": 0,
  "lastCommitDate": "2020-07-07T16:00:53.000Z",
  "lastCommentDate": "2020-07-07T21:57:41.000Z",
  "maintainerBlessed": false,
  "reviewLink": "https://github.com/DefinitelyTyped/DefinitelyTyped/pull/45893/files",
  "hasMergeConflict": false,
  "authorIsOwner": true,
  "isFirstContribution": false,
  "popularityLevel": "Popular",
  "anyPackageIsNew": false,
  "packages": [
    "underscore"
  ],
  "files": [
    {
      "filePath": "types/underscore/index.d.ts",
      "kind": "definition",
      "package": "underscore"
    },
    {
      "filePath": "types/underscore/underscore-tests.ts",
      "kind": "test",
      "package": "underscore"
    }
  ],
  "hasDismissedReview": false,
  "ciResult": "pass",
  "lastReviewDate": "2020-07-07T18:47:35.000Z",
  "reviewersWithStaleReviews": [],
  "approvalFlags": 2,
  "isChangesRequested": false
}

🔔 @borisyankov @jbaldwin @ccurrens @confususs @jgonggrijp @ffflorian @regevbr @peterblazejewicz - please review this PR in the next few days. Be sure to explicitly select Approve or Request Changes in the GitHub UI so I know what's going on.

👋 Hi there! I’ve run some quick measurements against master and your PR. These metrics should help the humans reviewing this PR gauge whether it might negatively affect compile times or editor responsiveness for users who install these typings.

Let’s review the numbers, shall we?

It looks like nothing changed too much. I won’t post performance data again unless it gets worse.

@reubenrybnik One or more reviewers has requested changes. Please address their comments. I'll be back once they sign off or you've pushed new commits or comments. If you disagree with the reviewer's comments, you can "dismiss" the review using GitHub's review UI. Thank you!

@jgonggrijp Thank you for reviewing this PR! The author has pushed new commits since your last review. Could you take another look and submit a fresh review?

Alright @jgonggrijp, I think I've got all the feedback here addressed whenever you're ready to take another look. Thanks for catching the explicit undefined memo issue and incorrect undefined return type when a memo is provided, I appreciate it! Sorry for not doing a better job of making sure I had a good understanding of these special cases this time around.

Thanks @jgonggrijp, you definitely saved me from doing some incorrect things in this one. It took longer than it should have for me to get that an explicitly undefined memo didn't work like I expected it to and I had for a while erroneously thought that you were asking me to collapse the overloads for handling the different memo cases back down to a single overload with an optional memo, which is probably why some of my comments seemed somewhat off the mark.

Plugging the final result into my company's solution, I end up with one new error because the result of a memoless call now also includes undefined in its result, which I believe to be correct.

Plugging the final result into my company's solution, I end up with one new error because the result of a memoless call now also includes undefined in its result, which I believe to be correct.

I agree, although you could try to prevent it by adding an even more specialized overload for memoless calls with an empty collection. It depends on how far you want to go; I'm fine with it either way.

I agree, although you could try to prevent it by adding an even more specialized overload for memoless calls with an empty collection. It depends on how far you want to go; I'm fine with it either way.

I did spend a bit of time thinking about this, but while TS does have the concept of an empty array type never[], I don't think it is likely to know that that's what it has except in trivial cases. For example, in the chain case previous operations could yield an array with stuff in it in some cases and an empty array in others.

I think the more interesting overload to add here would be one that drops undefined when TS knows it doesn't have an empty array, which I guess would be represented by the type [T, ...T[]], but it seems very unlikely that folks will end up with that type naturally or know that it could be useful to assert it. It would be more useful to add this overload if TS introduced a type guard around the concept of a length check that would transform a T[] into the appropriate tuple type that represents the known good length of the collection in the truthy branch, but I don't think such a thing is in place at this time unfortunately.

It looks like there's some discussion happening around such a type guard in microsoft/TypeScript#28837, so maybe at some point in the future it'll be more practical to add an overload like this. I can't think of any equivalent for dictionaries, though, so I think dictionaries are probably likely to forever go without.

Ready to merge