Adding reason-cli as a project development dependency

[ELLIOTTCABLE]

I see in the README that reason-cli suggests it be installed globally. For a variety of reasons, I consider that an anti-pattern; but more importantly, when permitting users to contribute to a project, I really don't want to add additional steps to a README (that users are already quite unlikely to actually read before attempting to play around with the source!) besides the standard preparation for a given language or platform.

For npm, that's npm install.

At the moment, it's non-trivial to clearly express my project's development-dependency on the OCaml tooling. I want to be able to indicate that to users, automatically, using reason-cli; but with the current version-numbering system, that leaves me a bit high and dry — I'd have to hardcode either ^X.X.X-macos or ^X.X.X-linux in the dependency declaration.

My options, right now:

1. Express an optionalDependencies entry against [email protected], for instance, and note in the README to Linux users that they'll need to manually swap that out for a Linux version. (I don't like to play favourites.)

2. Express a devDependencies entry against reason-cli@*, allowing npm to resolve a version. (This won't play well as BuckleScript development advances; as the versions of Merlin et al. presumably march in lockstep with compiler versions. Defeats the point of dependency-declarations at all!)

3. Drop any attempt to record the version semantically, and write-and-publish an npm prepare script or similar to install the appropriate reason-cli for the current system, given a version-id: npx install-reason-cli 3.3.3. Then record the currently-compatible version in the text of that script's invocation in the package.json. (That's more maintenance work and tooling, both on the publishing and consuming ends, that I don't want to get stale.)

4. Write and maintain a fork, with a single version-spec that ships all the binaries, and calls into the correct version at runtime. (Ew. For a bunch of reasons. But that's what I ended up going with for ELLIOTTCABLE/ppx-sedlex.)

I don't exactly have a Really Lovely solution to suggest — publishing compiled binaries to npm is a bit of a clusterfork right now; trust me, I know! — but I did want you to have the data-point that “not all of your users, both direct and transitive, want to install the package globally.” Maybe you can figure out a good approach that I missed. 😊