Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
Repo info
  • Oct 07 10:29
    hug0b commented #420
  • Aug 29 10:52
    robounohito edited #442
  • Aug 29 10:51
    robounohito edited #442
  • Aug 29 10:51
    robounohito edited #442
  • Aug 29 10:50
    robounohito opened #442
  • Jul 23 20:35
    edgarjrg opened #441
  • Jul 17 14:44
    masaeedu closed #187
  • Jul 16 19:08
    tycho01 commented #429
  • Jul 11 09:20
    tycho01 commented #440
  • Jul 11 07:29
    tgelu edited #440
  • Jul 11 07:29
    tgelu opened #440
  • Jul 03 17:18
    houd1ni commented #414
  • Jul 02 16:26
    ipanasenko opened #439
  • Jun 19 17:32
    bandreetto edited #438
  • May 17 21:20
    bandreetto edited #438
  • May 17 21:19
    bandreetto opened #438
  • May 01 15:28
    texastoland edited #437
  • May 01 15:27
    texastoland opened #437
  • Apr 17 13:56
    oleg-mtr edited #436
  • Apr 16 17:29
    oleg-mtr opened #436
Sam Stites
woah! I never knew this repo was around — I've slowly been chipping away on some definitions for the past 6 months
Robin Wenglewski
Thanks for the typings. What to you think about making R.Lens a generic? Don't know about other use cases, but for me all lenses are to a certain type. Feels weird that the lens does not have a type, and instead I have to provide it every time I use view/set/over
Tycho Grouwstra
Hey guys. I just cloned this hoping to add a bit. After following the instructions to run the tests I'm getting many type errors though. Might tsc be using my global (newer) TS version rather than the local 1.8.x?
Tycho Grouwstra
On another note, it seems more recent TS versions have been adding a lot of functionality. Might it be a consideration to upgrade?
Tushar Mathur
Hi, I was wondering if the placeholder thingy has been released?
I could not get to install it somehow
And if not what's the alternative?
Tycho Grouwstra
@tusharmath hey, placeholders can't be dealt with type-wise yet
Flip should work
Casey Link
hey folks is it read to use this library for ramda+typescript in a side project?
I just picked it up 5 minutes ago and already ran into a problem with using R.map on an object :\
Hello all! I've been wanting to use Ramda for over a year now. Now, I've the go ahead (well sorta) to use it in production. I'm new to TypeScript and new to using Ramda in production.
I'd like to know if there is a writeup on how to actually use them together properly. (Writing JS with types is already something I'm kinda struggling with) :smile:
Casey Link
@wayneseymour I've been using the https://github.com/types/npm-ramda/ library with success
Wojciech Karaś

I have some problem with pipe method from ramda.

//pipe<V0, T1>(fn0: (x0: V0) => T1): (x0: V0) => T1;
const foo: (x: number) => number = R.pipe((x) => x + x);

//pipe<V0, V1, T1>(fn0: (x0: V0, x1: V1) => T1): (x0: V0, x1: V1) => T1;
const bar: (x: number, y: number) => number = R.pipe((x, y) => x + y);

First example work correctly, but in second case x and y is any. I think this is probably bug in TS, because typings looks good to me, but can't find any similar issue on github to track. Does anyone have similar problem or recall any issue pointing to this problem?

Garrett Dawson
Heya folks—having trouble typing out a reduce:
reduce<string[], (keyof T)[]>(
      (acc, propName) => acc.concat(prop(propName, errors)),
Argument of type 'string[]' is not assignable to parameter of type 'ReadonlyArray<string[]>
Garrett Dawson
I actually have the type params in reduce backwards—should be reduce<keyof T, string[]>, but just getting that ReadonlyArray mismatch
Garrett Dawson
re-arranged some stuff, have it typechecking, but still have an any I can’t eliminate—here’s the entire functions
export function getErrorMessages<T> (errors: FormikErrors<T>, touched: FormikTouched<T>) {
  const _keys = keys(touched)

  const messages = compose(
    reduce<string, string[]>(
      (acc, propName) => acc.concat(prop(propName as any, errors)),

  return messages(_keys)
basically flattens out so I have an array of string derived from props that exist in both errors and touched—might be that it’s just not the right approach, which TS is hinting at
Rodrigo Juarez

hi! I'm having some problems with ramda with and TS

 compose(all(predicate), defaultTo([]));

that code tells me that it's expecting 0 arguments
but defaultTo already expects the second argument

Tycho Grouwstra
please file any issues at https://github.com/types/npm-ramda/issues/
Garrett Dawson
Garrett Dawson
been trying to get typed ramda working, but often hit hard to understand issues. An example:

type FooBar = {
  foo: number
  bar: number

function sortFooBar (list: FooBar[]) {
  const getFoo = prop<'foo', FooBar>('foo')
  const getBar = prop<'bar', FooBar>('bar')

  const sortFoo = ascend(getFoo)
  const sortBar = ascend(getBar)

  const fn = sortWith([ sortFoo, sortBar ])

  return fn(list)

const foobars = [{ foo: 1, bar: 2 }, { foo: 3, bar: 2 }]
produces Property 'bar' is missing in type 'Record<"foo", FooBar>'.
decomposed the separate functions to locate where the type issue is occurring. sortWith is unhappy
Nate Abele
Hey y'all... as I'm sure many of you are aware, TypeScript finally landed a patch for proper higher-order type inference (Microsoft/TypeScript#30215 :tada:)—has there been any kind of effort towards updating the type definitions to properly support this? If so, is it being tracked somewhere?