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 optionalDependencies entry against reason-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 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!)
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.)
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. :blush:
I see in the README that
reason-clisuggests 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-macosor^X.X.X-linuxin 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
npmis 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. :blush: