Convert the following packages to `npm`

[jordwalke]

We now allow installation of Reason via npm (for use cases such as Atom plugins, or anyone else that would like to use npm to build Reason apps).

There's two missing pieces when installing Reason via npm: rtop and jengaboot. The reason is that utop, and jenga (dependencies of rtop and jengaboot respectively) aren't yet converted to npm packages. We need to npmify utop, jenga, and all their respective dependencies. I've already done some of them, but this would be good to crowd source.

The current approach to porting to npm is that we're forking each project to the npm-ml account, finding the commit of an important version (for example where 1.3.2 was cut), adding a package.json on top of that commit which turns the findlib package into an npm package, and then tagging that commit as npm-1.3.2 (the commit that adds the package.json and gets tagged is a floating commit not merged into the main history). We do not yet actually push to npm because npm doesn't actually require npm (the service) - we may use github instead (though it has drawbacks such as not working with version range constraints in package.json).

I've done this for many of the dependencies, but there's a long list remaining and it would be best to crowd-source the effort so people can get a feel for how findlib packages can work on npm. I'll post more detailed instructions, but for now, read the package.json files for the ones I've already ported to see how it woks. Here's what we need to get on npm.

rtop:

• [ ] utop: oasis is listed as a dependency, but only for building the dev version of utop. We don't need to convert oasis to npm (thankfully).
  • [ ] lambda-term {>= "1.2"}.
  • [ ] lwt
  • [ ] react {>= "1.0.0"} (the ocaml React)
  • [x] cppo {>= "1.1.2"} Done

    jengaboot:

• [ ] jenga + its dependencies. jenga depends on core - we might consider another approach than porting all the dependencies. Please feel free to update this issue with the transitive deps of each package here.
• [ ] js_of_ocaml](https://github.com/ocsigen/js_of_ocaml) + its dependencies.
• [x] yojson + its dependencies Done

  merlin (done):

• [x] yoson + its dependencies Done

Merlin is a really important thing to be able to compile on npm, much more than rtop.

We cannot precompile jengaboot into portable bytecode because jengaboot happens to "ocaml plugin" which is cool, but doesn't work in bytecode mode.

[yunxing]

Haven't done any conversion yet.. Do you think this can be automated? @chenglou @jordwalke ,

[jordwalke]

I think it can be automated for opam packages. We could construct the package.json postinstall step from the opam build field. We could then compile opam-installer to bytecode (or JS) which takes generated packageName.install files and installs them to a location of your choosing. Maybe it's more involved than that?

[jordwalke]

Here are the details about how to port packages to npm

https://github.com/npm-ml/ocaml-findlib/wiki/Porting-OCaml-packages-to-npm.

[jordwalke]

People who would be interested in that: @chenglou @yunxing @bsansouci @SanderSpies @texastoland

[jordwalke]

Updated this with our needs to port merlin to npm.

[rickyvetter]

We do not yet actually push to npm because npm doesn't actually require npm (the service) - we may use github instead (though it has drawbacks such as not working with version range constraints in package.json).

Is the main issue with using npm naming collisions? If so, I think that using scoped packages the same way cycle pushes modules is a pretty elegant solution here. It allows the modules to maintain their names inside of npm and clarifies that they are not JS packages. I'm squatting on the ocaml user which would allow us to publish modules as @ocaml/{module}. Didn't see any other fantastic names for scoping that were available.

[texastoland]

Strongly agree about scoping. It's nice to have a bare reason and the remainder as @reason/{ocaml}. TypeScript is doing the same thing with @types.

[rickyvetter]

reason would be great - currently owned but it has no packages - https://www.npmjs.com/~reason. Might be worth reaching out. reasonml is available, but pretty lengthy for a prefix. ml is also owned with no packages and it looks like a secondary account for medallia, so there might be some flexibility there.

[texastoland]

Just reach out to the author and/or support@npmjs.com:

Thanks for having a conversation and CC'ing npm support.

I noticed you have some empty packages that would fall under our squatting policy. Please note that if another user reaches out to us requesting a package name of yours that's empty, we would transfer it to them.

You can learn more about our package name policies here: https://www.npmjs.com/policies/disputes#exceptions

[jordwalke]

We already have several packages that we would push to the reason scope, if we had it. We also have the npm package reason. I'm not sure how scopes work, but I'd like for everyone to be able to push to the reason scope. Are scopes really what we want in that case?

One benefit to using git urls is that it's one less service to register for, one less thing to push to, and it would be nice to not worry about namespace collisions. Each github user basically acts as a separate "scope".

[texastoland]

npm scopes are users like GitHub. TypeScript pulls theirs in from DefinitelyTyped via automation. Might be a neat trick for OPAM too.

[jordwalke]

I've successfully converted Merlin to an npm package here.

Now, we just need to have the editor plugins look inside of the closest node_modules to the first .re/i file opened in the editor session, in order to find the vim/emacs/Atom files for merlin. I created an issue here. It's a good first task too.

[chenglou]

Can this be closed, now that we have auto conversion?

Would be good to document the process though.