Add types-ramda to allowedPackageJsonDependencies

[Harris-Miller]

Specifically for this MR: DefinitelyTyped/DefinitelyTyped#64939

ramda is moving type definitions in house with in the intention for those types to exist within the main ramda package. In the meanwhile, @types/ramda will re-export the new types-ramda package while we solidify the existing types and work on the next ramda release that will include those types in-package

[andrewbranch]

Sorry if this is a dumb question, but why wouldn’t the first-party ramda types just be published in ramda? The approach you’re planning on using here, while it appears to be well-thought-out, has some pitfalls you may not have been aware of.

Packages in node_modules/@types are treated specially by TypeScript as standing in for their non-@types counterpart. You can’t achieve the same behavior with a package like node_modules/types-ramda. The only reason imports of "ramda" will be typed is because @types/ramda is doing a re-export. But this has two pretty bad implications:

1. You will need the nearly-empty @types/ramda package indefinitely, not just during a transition.
2. types-ramda will appear to be an implementation package that stands on its own, so users will be free to write imports from "types-ramda" when really they should import from "ramda". Auto-imports will even suggest that users import "types-ramda".

Any time you have a module .d.ts file, as you have throughout "types-ramda", it asserts that there is a .js file by the same name next to it. The only time this isn’t true is when the file is in an @types package, where it asserts that the corresponding js file is in a non-@types package by the same name.

[Harris-Miller]

@andrewbranch
Single source of truth is the main issue. The ramda core team does not want to do incremental releases for typing updates yet, but we do want to begin bringing types in-house. We cannot do that AND have the community defined @types/ramda. Managing two sets of typing definitions would be a nightmare.

So it makes sense to bring them in-house now to work on, and have @types/ramda just re-export them. The end-game is to eventually merge the types-ramda repo directly into ramda so types are first-class. Until then, this is our stepping stone

1. You will need the nearly-empty @types/ramda package indefinitely, not just during a transition.

True, and is our expectation. But like any repo before that had a @types/repo before types were first-class, @types/ramda will be deprecated once they are brought in to be first-class as well

2. types-ramda will appear to be an implementation package that stands on its own, so users will be free to write imports from "types-ramda" when really they should import from "ramda". Auto-imports will even suggest that users import "types-ramda".

types-ramda is not intended to be used outside of this, and we can explain in the README how that package is not ever meant to be used directly, and instead to use @types/ramda