@rescript/core: dependency or peerDependency?

1

Is there an official recommendation on where to put @rescript/core in packages?

1 Like
2

Put it in dependency. You treat it like you would treat helper functions, they are essential to your package to work. I treat peerDeps as optional, so if it’s not optional, in dependencies it goes.

3

FWIW There’s a peerDependenciesMeta to define if peer dependency is optional.

1 Like
4

i know, i just don’t find it helpful to make the distinction between optional and not-optional peer dependencies, so I don’t. To me this is a typical example of some dev bubble introducing a concept that I didn’t need. If it’s a peer dependency, your/my package doesn’t need it, to work. Why add optional on top? Peers were supposed to define common dependencies with other packages. A depends on X, B depends on X, A is a peer to B. To my package, it’s absolutely irrelevant, if it’s peer is optional or not.

5

These are questions to Node/NPM folks, but the existing semantics of the field is different from what you described. The main problem is that it is not enforced.

6

Also keep in mind, that I described two parts. A direct answer to where core should go and why, and an extended explanation of how I go beyond that, indicated by me describing how I work with peerDeps, and both statements stand on their own.

7

It depends, just same as normal JS packages.

Generally it should be peerDeps if you publish a library, otherwise put into dependency if you build app.

More specifically, peerDeps describes requirements for dependencies to be hosted on end-user site. It’s mainly needed for toolchains such as plugin systems, compilers, and meta-frameworks.

It is also the ReScript module system expects, because even if there are multiple dependency versions, your package manager may chooses one main path, and ReScript internally rely on that assumption.