Skip to content
This repository was archived by the owner on Oct 24, 2023. It is now read-only.
This repository was archived by the owner on Oct 24, 2023. It is now read-only.

Adding reason-cli as a project development dependency #97

@ELLIOTTCABLE

Description

@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 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.)

  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. 😊

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions