-
Notifications
You must be signed in to change notification settings - Fork 22
Adding reason-cli as a project development dependency #97
Description
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:
-
Express an
optionalDependenciesentry againstreason-cli@X.X.X-macos, 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.) -
Express a
devDependenciesentry againstreason-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!) -
Drop any attempt to record the version semantically, and write-and-publish an
npm preparescript or similar to install the appropriatereason-clifor 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 thepackage.json. (That's more maintenance work and tooling, both on the publishing and consuming ends, that I don't want to get stale.) -
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. 😊