Welcome to the ReScript compiler project!

This document will give you guidance on how to get up and running to work on the ReScript compiler and toolchain.

(If you want to contribute to the documentation website, check out rescript-association/rescript-lang.org.)

We tried to keep the installation process as simple as possible. In case you are having issues or get stuck in the process, please let us know in the issue tracker.

Happy hacking!

Most of our contributors are working on Apple machines, so all our instructions are currently macOS / Linux centric. Contributions for Windows development welcome!

• NodeJS v18
• C compiler toolchain (usually installed with xcode on Mac)
• Python <= 3.11 (required to build ninja)
• Rust toolchain (required to build rewatch; follow the instructions at https://www.rust-lang.org/tools/install)
• opam (OCaml Package Manager) v2.2.0
• VSCode (+ OCaml Platform Extension)

The rescript-compiler git repo is very large because, prior to tooling improvements made for ReScript 11 development, build artifacts were checked in to the repo ("snapshotted"). Therefore, cloning the repo in full will consume a lot of bandwidth and disk space (> 2GB).

If you are only interested in the latest master commit, you can perform a shallow clone instead as follows:

git clone --depth 1 https://github.com/rescript-lang/rescript-compiler.git

This will only consume less than 50MB.

The ReScript compiler compiles with any recent OCaml compiler. We are using dune as a build system for easy workflows and proper IDE support.

Make sure you have opam installed on your machine.

opam init

# Any recent OCaml version works as a development compiler
opam switch create 5.2.0 # can also create local switch with opam switch create

# Install dev dependencies from OPAM
opam install . --deps-only --with-test --with-dev-setup -y

Run npm install --ignore-scripts. This will install the npm dependencies required for the build scripts.

As an alternative to the manual installation, the repository provides a development container definition that can be used with VS Code's Remote Containers extension. Use this to get a stable development environment without having to install anything locally other than VS Code and Docker.

Run the Dev Containers: Rebuild and Reopen in Container action to get started.

You can also open this dev container with GitHub Codespaces.

The compiler binaries themselves can be built directly with dune as follows:

# One off build
dune build

# Watch mode
dune build -w

For all additional operations, a Makefile is provided:

# Build the compiler using dune and copy the exes into the platform dir
make

# Build the ninja build tool
make ninja

# Build the ReScript standard library using ninja and the compiler
make lib

# Run compiler tests
make test

# Run syntax tests
make test-syntax

# Run syntax tests including roundtrip tests
make test-syntax-roundtrip

# Populate lib/ocaml and update artifact list
make artifacts

• OCaml Code: snake case format is used, e.g, to_string
• ReScript Code: the camel case format is used, e.g toString

To make sure that no files are added to or removed from the npm package inadvertently, an artifact list is kept at packages/artifacts.txt. During CI build, it is verified that only the files that are listed there are actually included in the npm package.

After adding a new file to the repository that should go into the npm package - e.g., a new stdlib module -, run make artifacts.

make lib # Build compiler and standard library
./bsc myTestFile.res

make artifacts # Build compiler and standard library and populate lib/ocaml
npm link
cd myProject
npm install
npm link rescript

We provide different test suites for different levels of the compiler and build system infrastructure. Always make sure to locally build your compiler before running any tests.

To run all tests:

make test

Run Mocha tests only (for our runtime code):

This will run our mocha unit test suite defined in tests/tests.

node scripts/test.js -mocha

Run build system test (integration tests):

This will run the whole build system test suite defined in tests/build_tests.

node scripts/test.js -bsb

Run ounit tests:

This will run unit tests for compiler related modules. The tests can be found in tests/ounit_tests.

node scripts/test.js -ounit

The runtime implementation is written in ReScript with some raw JS code embedded (runtime directory).

The goal is to implement the runtime purely in ReScript. This includes removing all existing occurrences of embedded raw JS code as well whenever possible, and you can help!

Each new PR should include appropriate testing.

Currently all tests are located in the tests/tests directory and you should either add / update test files according to your changes to the compiler.

There are currently two formats for test files:

1. Mocha test files that run javascript test code
2. Plain .res files to check the result of compilation to JS (expectation tests)

Below we will discuss on how to write, build and run these test files.

• Create a file tests/tests/src/feature_abc_test.res. Make sure to end the file name with _test.res.

• Inside the file, add a mocha test suite. The mocha bindings are defined in tests/tests/src/mt.res. To get you started, here is a simple scaffold for a test suite with multiple test cases:

  let suites: Mt.pair_suites = list{
    ("hey", _ => Eq(true, 3 > 2)),
    ("hi", _ => Neq(2, 3)),
    ("hello", _ => Approx(3.0, 3.0)),
    ("throw", _ => ThrowAny(_ => raise(SomeException))),
  }
  
  Mt.from_pair_suites(__MODULE__, suites)

• Build the test files and run the tests: node scripts/test.js -mocha.

This is usually the file you want to create to test certain compile behavior without running the JS code formally as a test, i.e., when you just want to check that the ReScript code compiles and produces the expected JS code.

• Create your test file tests/tests/src/my_file_test.res. Make sure to end the file name with _test.res.
• Build the .js artifact: node scripts/test.js -mocha.
• Verify the output, check in the tests/tests/src/my_file_test.res and tests/tests/src/my_file_test.js to version control. The checked in .js file is essential for verifying regressions later on.
• Eventually check in other relevant files changed during the rebuild (depends on your compiler changes).

The "Playground bundle" is a JS version of the ReScript compiler; including all necessary dependency files (stdlib / belt etc). It is useful for building tools where you want to compile and execute arbitrary ReScript code in the browser.

The ReScript source code is compiled with a tool called JSOO (js_of_ocaml), which uses OCaml bytecode to compile to JavaScript and is part of the bigger OCaml ecosystem.

Install jsoo via opam:

opam install js_of_ocaml.4.0.0

The entry point of the JSOO bundle is located in compiler/jsoo/jsoo_playground_main.ml, the compiler and its relevant runtime cmij files can be built via make:

make playground
make playground-cmijs

Note that building the cmijs is based on the dependencies defined in packages/playground-bundling/package.json. In case you want to build some different version of e.g. @rescript/react or just want to add a new package, change the definition within the package.json file and run make playground-cmijs again.

After a successful compilation, you will find following files in your project:

• playground/compiler.js -> This is the ReScript compiler, which binds the ReScript API to the window object.
• playground/packages -> Contains third party deps with cmij.js files (as defined in packages/playground-bundling/bsconfig.json)
• playground/compilerCmij.js -> The compiler base cmij containing all the relevant core modules (Js, Belt, Pervasives, etc.)

You can now use the compiler.js file either directly by using a <script src="/path/to/compiler.js"/> and <script src="/path/to/packages/compilerCmij.js"/> inside a html file, use a browser bundler infrastructure to optimize it, or use nodejs to run it on a command line:

$ node
> require("./compiler.js");
> require("./packages/compilerCmij.js")
> let compiler = rescript_compiler.make()
> let result = compiler.rescript.compile(`Js.log(Sys.ocaml_version)`);
> eval(result.js_code);
4.06.2+BS

Run node playground/playground_test.js for a quick sanity check to see if all the build artifacts are working together correctly. When releasing the playground bundle, the test will always be executed before publishing to catch regressions.

Whenever you are modifying any files in the ReScript compiler, or in the jsoo_playground_main.ml file, you'll need to rebuild the source and recreate the JS bundle.

make playground

# optionally run your test / arbitrary node script to verify your changes
node playground/playground_test.js

Note: If you want to publish from your local machine, make sure to set the KEYCDN_USER and KEYCDN_PASSWORD environment variables accordingly (credentials currently managed by @ryyppy). Our CI servers / GH Action servers are already pre-configured with the right env variable values.

Our compiler.js and third-party packages bundles are hosted on KeyCDN and uploaded via FTPS.

The full release can be executed with the following make script:

make playground-release

The script will automatically detect the ReScript version from the compiler.js bundle and automatically create the correct directory structure on our CDN ftp server.

Note that there's currently still a manual step involved on rescript-lang.org to make the uploaded playground version publicly available.

The API reference is generated from doc comments in the source code. Here's a good example.

Some tips:

• The first sentence or line should be a very short summary. This is used in indexes and by tools like merlin.
• Ideally, every function should have at least one @example.
• Cross-reference another definition with {! identifier}. But use them sparingly, they’re a bit verbose (currently, at least).
• Wrap non-cross-referenced identifiers and other code in [ ... ].
• Escape {, }, [, ] and @ using \.
• It’s possible to use {%html ...} to generate custom html, but use this very, very sparingly.
• A number of "documentation tags" are provided that would be nice to use, but unfortunately they’re often not supported for `external`s. Which is of course most of the API.
• @param usually doesn’t work. Use {b <param>} ... instead
• @returns usually doesn’t work. Use {b returns} ... instead.
• Always use @deprecated when applicable.
• Always use @raise when applicable.
• Always provide a @see tag pointing to MDN for more information when available.

See Ocamldoc documentation for more details.

To generate the html:

../scripts/ninja docs

The highlevel architecture is illustrated as below:

Source Language
  |
  | (Parser)
  v
Surface Syntax Tree
  |
  | (Built-in Syntax tree transformation)
  v
Surface Syntax Tree
  |
  | (Reuse OCaml Type checker)
  v
Typedtree
  |
  | (Reuse OCaml pattern match compiler and erase types)
  v
Lambda IR (OCaml compiler libs) ---+
  |   ^                            |
  |   |                     Lambda Passes (lam_* files)
  |   |             Optimization/inlining/dead code elimination
  |   \                            |
  |    \ --------------------------+
  |
  |  Self tail call elimination
  |  Constant folding + propagation
  V
JS IR (J.ml)  ---------------------+
  |   ^                            |
  |   |                     JS Passes (js_* files)
  |   |            Optimization/inlining/dead code elimination
  |   \                            |
  |    \  -------------------------+
  |
  |  Smart printer includes scope analysis
  |
  V
Javascript Code

Note that there is one design goal to keep in mind, never introduce any meaningless symbol unless necessary, we do optimizations, however, it should also compile readable output code.

Target branch master for development of new (breaking) features (v12).

Bug fixes and maintenance should target branch 11.0_release. We'll merge 11.0_release into master from time to time to propagate those changes.

To build a new version and release it on NPM, follow these steps:

1. Verify that the version number is already set correctly for the release. (It should have been incremented after releasing the previous version.)
2. Create a PR to update CHANGELOG.md, removing the "(Unreleased)" for the version to be released.
3. Once that PR is merged and built successfully, tag the commit with the version number (e.g., "v10.0.0", or "v10.0.0-beta.1") and push the tag.
4. This triggers a tag build that will upload the playground bundle to KeyCDN and publish the rescript and @rescript/std npm packages with the tag "ci".
5. Verify that the playground bundle for the new version is now present on https://cdn.rescript-lang.org/.
6. Run npm info rescript to verify that the new version is now present with tag "ci".
7. Test the new version.
8. Tag the new version as appropriate (latest or next):
   • npm dist-tag add rescript@<version> <tag>
   • npm dist-tag add @rescript/std@<version> <tag>
9. Create a release entry for the version tag on the Github Releases page, copying the changes from CHANGELOG.md.
10. Create a PR with the following changes to prepare for development of the next version:
    • Increment the version number in package.json for the next version.
    • Run node scripts/setVersion.js to take that version number over into other files.
    • Update CHANGELOG.md and add an entry for the next version, e.g., "10.0.0-beta.2 (Unreleased)"
11. Coordinate any forum/blog posts with @ryyppy.

To reproduce issues, it can be helpful to the team to install a specific version of the compiler. To do so:

1. Go to Actions CI for master
   • If you need a specific branch, select a different one to filter to in the GitHub UI.
2. Select a specific run (likely the latest)
3. Under "Artifacts", download the npm-packages artifact and extract it to a folder.
4. In your repository run:

npm i <path_to_download>npm-packages/rescript-*.tgz

1. Then attempt to rebuild your project as you would normally.

Since ReScript is distributed under the terms of the LGPL Version 3, contributions that you make are licensed under the same terms. In order for us to be able to accept your contributions, we will need explicit confirmation from you that you are able and willing to provide them under these terms, and the mechanism we use to do this is called a Developer's Certificate of Origin DCO. This is very similar to the process used by the Linux(R) kernel, Samba, and many other major open source projects.

To participate under these terms, all that you must do is include a line like the following as the last line of the commit message for each commit in your contribution:

Signed-Off-By: Random J. Developer <random@developer.example.org>

You must use your real name (sorry, no pseudonyms, and no anonymous contributions).