npm package for require("melange"), require("melange.belt"), and require("melange.runtime")

[haochenx]

When code compiled by melange contains usage of certain Stdlib modules / Belt / Caml module, the generated code contain require("melange/./..."), require("melange.belt/./..."), and/or require("melange.runtime/./...").

It would be nice if those "standard libraries" are available on npmjs.org. This will ease integration with modern javascript projects.

Also, it's worthy to consider

• pack the three packages to a single umbrella package (e.g. melange-std, as the package name melange is already taken on npm)
  • thus the invocations to require would be e.g. require("melange-std/stdlib/..."), require("melange-std/belt/..."), and require("melange-std/runtime/...")
• allow specifying of the package names for the standard libraries in the newly added melange.emit stanza
  • e.g. make it possible to have the generate code uses
    • require("../melange-support/./...") instead of require("melange/./...")
    • require("../melange-support.belt/./...") instead of require("melange.belt/./...")
    • require("../melange-support.runtime/./...") instead of require("melange.runtime/./...")

(testing with melange.1.0.0 + dune.3.8.0)

[jchavarri]

I am not sure I understand the use case for this issue. Melange will place a node_modules folder that includes the generated JavaScript files for these 3 libraries. For example, in melange-opam-template:

$ ls  _build/default/src/output/node_modules
melange  melange.belt  melange.runtime  reason-react

This allows to integrate with any javaScript projects, due to node_modules resolution algorithm.

Do you have any use cases in mind for publishing the packages in npm? This comes with its own sets of issues (mainly, how to pin down that a given package in npm has been published with a given version of melange).

[haochenx]

Thank you for taking a look.

There are at least the following use cases I can immediately think of:

1. easier integration with js bundlers (e.g. webpack, metro)
   • not all bundlers support nested node_modules out-of-box and relative path will always works
2. mono repo with multiple melange-powered (sub-)projects
   • in a js/ts centric mono repo, there could be multiple libraries that must be self-contained (although inter-dependency could usually be handled without problem.) in this case, you will want either
     1. a single copy of node_modules/melange* in the workspace node_module folder, or
     2. relative reference to melange*-libs
3. multi-language mono repo
   • in a multi-language mono repo setup, not every developer's environment is expected to have ocaml environment installed.
     in this case, instead the compiled js files are checked in (as per ReScript's recommendation)
4. published package
   • (iiuc) it is near to impossible to publish a melange package that uses stdlib/belt now

We have projects in hand that hits the first three bullet points above.

[anmonteiro]

I could see this being useful in combination with (emit_stdlib false), and shouldn't be too much hassle when releasing a new version.