Add zipEqual and zipLongest

[cjquines]

Two related but separate proposals:

• zipEqual, which would be the equivalent of zip(..., strict=True) from Python or itertools::zip_eq from Rust.
• zipLongest, which would be the equivalent of itertools.zip_longest from Python and the approximate equivalent of transpose from Ramda.
  • Options include adding a fill element like itertools.zip_longest, or omitting like transpose.

[eranhirsch]

I'm not sure these add enough, the user would have to read several function's documentation just to make sure they are using the correct version. I think that our current zip implements the most expected version of the function as is common in other libraries, and if users need their own variant they can always write their own utility.

I do think that we should add an invariant function that can throw on a provided predicate similar to an inline invariant. Having that would allow users to implement zipEqual via 2 lines of a pipe:

const x = pipe(
  ...
  invariant(isLength(other.length)),
  zip(other),
  ...
);

[eranhirsch]

@TkDodo, wdyt?

[cjquines]

invariant would be interesting, especially if you could use it with type guards:

const data: number | string = "a";
const x = R.pipe(
  data,
  R.invariant(R.isNumber),
  R.add(2), // ok
);

why not the name assert?

[eranhirsch]

I think I tried using assert in the past and encountered some problem, but I don't remember the specifics and agree it could be called assert if it works.

[Powell-v2]

hi @eranhirsch, I'd like to lend a hand with this one - have you already decided on the desired implementation strategy?

[eranhirsch]

I don't believe this request is general enough to grant adding to the library. Others are asking if we can add a zip function that would take an arbitrary number of arrays instead of just 2. Together with that request, the number of zip functions we will end up supporting would be too big because of limitations to how Remeda can support optional params and kwargs-style params, which it simply can't because of our runtime currying; it requires every variant to be a top-level util.

These utils could be implemented on top of Remeda with a short helper function of 5-10 lines of code.

I'll leave the issue open so others can comment, but for now, I don't support adding these.

[Powell-v2]

Thanks for the update! Fair enough. Which areas of the library could use some help from your point of view? Happy to begin contributing to the project : )

[eranhirsch]

There are a few functions that need more test coverage. Tests are always a good addition because they allow us to ensure we continue delivering a high-quality library while we change, modernize, and fix stuff. This is especially useful for us going into V2 as we are going to change, modernize, and fix quite a few things 😉

[Powell-v2]

Of course, testing is foundational : ) Could you please give me some pointers?

[eranhirsch]

Any test file that is short, lacks interesting cases, or has an issue in the testing code itself. Just notice that we are deprecating some functions, so avoid those test files (see the @deprecated tag in the function impl).