Reason: support node modules?

[matthewmueller]

i don't think it'd work so well when compiling to native but for compiling to JS it would be nice to support.

may create interop issues, but the node ecosystem is pretty massive, so it'd be nice to be able to tap into that when needed.

[jordwalke]

There's many different spins on this idea and feel free to elaborate what you had in mind.

One use case is package.json to express your set of Reason dependencies, and then installing their source code into a sandbox (node_modules), then building all of your deps (and yourself) from the root directory.

CommonML does this. The ReasonExampleProject shows how you can use npm to wire together many npm modules into one monolithically built native binary. @chenglou is working on a faster and more scalable build system built on Jenga that impemens that exact same workflow (but faster) https://github.com/chenglou/jengaboot

But did we need to use npm to accomplish that? Really what we're after is the workflow that npm offers and npm just happens to already provide that. We'd also like to build a bridge to the opam world so we can achieve that same workflow inside of opam.

Any other ideas about ways we could take inspiration from the npm world? Everything I mentioned so far was with respect to having Reason dependencies in your node_modules, but maybe you meant that you could interop with JS dependencies?

[chenglou]

(Jengaboot repo still dirty and I tweaked some stuff before publishing. Feedback welcome on that repo)

[matthewmueller]

thanks for the links guys! i'm also trying to get a better sense of where this project fits in with the existence of flow, typescript, etc.

@jordwalke i haven't thought about it too much, but at a high-level this is what i want to be able to do:

index.re:

// include express framework
include express

let module Login {
  let loginTwice = fun auth => {
    (login auth, login auth)
  }
}

console.log 'hi'

CLI:

reason index.re
# => hi

personally, i don't really care what runtime this runs on top of (node or ocaml) as long as it executes quickly and is easy to install.

basically i'd love a fast, optionally-typed javascript-like language that can compile natively and to an optimized javascript (asm or web assembly) for the browser 🎉

[IwanKaramazow]

I think @matthewmueller meant interop with JS dependencies like

// someNodeModule.js
module.exports = function () { console.log('bar'); }

From what I understand this isn't possible yet? I'm waiting on Bucklescript support for any of this interop.

The workflow makes a lot of sense to me, but what's the motivation behind node_modules for Reason dependencies? Wouldn't modules be a better name in general? I mean this isn't a javascript project, less confusion.

[matthewmueller]

@IwanKaramazow absolutely, sorry I just wrote node_modules to get my point across. but this doesn't need to depend on node or how NPM installs things.

[jordwalke]

basically i'd love a fast, optionally-typed javascript-like language that can compile natively and to an optimized javascript (asm or web assembly) for the browser 🎉

A type system and the kind of compilation you can hope for are deeply connected. OCaml, and therefore Reason, are very much statically typed. It is _because_ of that property that you can benefit from the ability to have your libraries be compiled into JS _or_ efficient machine instructions.

However, when you compile your strict code into JS, we should seek to be able to seamlessly interop with existing JS libraries even though they are not strict. In this sense, you can think about Reason+OCaml as your goto tool for building libraries for which you want the most _options_ (you want to be able to run your newly built library in performance sensitive applications, but you _also_ want to use it in your JS apps etc).

The interop between JS libraries is not automated yet (you can see the Reason Atom plugin itself which does some of this interop). It's pretty manual right now, but there's certainly a lot of potential. It looks like the BuckleScript compiler aims to help make that node module interop easy.

I like the workflow you aim for, and I hope we can achieve it.

[bobzhang]

@matthewmueller hi, bucklescript supports this workflow out of the box, see example, and more than that, you can share your ocaml modules as JS modules, just like typescript.

We are working on integrating reason into bucklescript, see this issue #419 , but you can still try vanilla ocaml syntax, and when it is ready, you can use refmt to upgrade to reason syntax

Edit: actually you can already use reason with buckle, since bucklescript support -pp option

[jordwalke]

That sounds awesome @bobzhang. I did not know it was so far along already.

[bobzhang]

@jordwalke seamless integration with npm ecosystem is our main goal.
Even for server side, nodejs still makes lot of sense, it has tons of libraries, and easier to deploy to cloud like AWS lambda
For front-end, we support various module systems, amd/commonjs and even google module for google closure users, once es6 lands in nodejs, we will support es6 modules too

[kennetpostigo]

Is this okay to close? I think bucklescript should support this workflow.

[chenglou]

Yep. See examples in https://github.com/reasonml-community =D

[teohhanhui]

I think this issue is about using node modules from OCaml / Reason, which in fact requires BuckleScript bindings to be written for the JS libraries.