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 v16
- C compiler toolchain (usually installed with
xcode
on Mac) opam
(OCaml Package Manager)- 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 4.14.0 # can also create local switch with opam switch create . 4.14.0
# Install dev dependencies from OPAM
opam install . --deps-only
# For IDE support, install the OCaml language server
opam install ocaml-lsp-server
Run npm install --ignore-scripts
. This will install the npm dependencies required for the build scripts.
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
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 jscomp/test
.
node scripts/ciTest.js -mocha
Run build system test (integration tests):
This will run the whole build system test suite defined in jscomp/build_tests
.
node scripts/ciTest.js -bsb
Run ounit tests:
This will run unit tests for compiler related modules. The tests can be found in jscomp/ounit_tests
.
node scripts/ciTest.js -ounit
The runtime implementation is written in OCaml with some raw JS code embedded (jscomp/runtime
directory).
The goal is to implement the runtime purely in OCaml. 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 jscomp/test
directory and you should either add / update test files according to your changes to the compiler.
There are currently two formats for test files:
- Mocha test files that run javascript test code
- 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
jscomp/test/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
jscomp/test/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:
node scripts/ninja.js clean && node scripts/ninja.js build
. -
Run the tests:
npx mocha jscomp/test/**/*test.js
.
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
jscomp/test/my_file_test.res
. Make sure to end the file name with_test.res
. - Build the
.js
artifact:node scripts/ninja.js config && node scripts/ninja.js build
. - Verify the output, check in the
jscomp/test/my_file_test.res
andjscomp/test/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 jscomp/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 thewindow
object.playground/packages
-> Contains third party deps with cmij.js files (as defined inpackages/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
andKEYCDN_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 compiler sources include a list of reserved JS keywords in jscomp/ext/js_reserved_map.ml
which includes all identifiers in global scope (window
). This list should be updated from time to time for newer browser versions.
To update it, run:
npm install puppeteer
node scripts/build_reserved.js
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:
- Verify that the version number is already set correctly for the release. (It should have been incremented after releasing the previous version.)
- Create a PR to update
CHANGELOG.md
, removing the "(Unreleased)" for the version to be released. - 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.
- 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". - Verify that the playground bundle for the new version is now present on https://cdn.rescript-lang.org/.
- Run
npm info rescript
to verify that the new version is now present with tag "ci". - Test the new version.
- Tag the new version as appropriate (
latest
ornext
):npm dist-tag add rescript@<version> <tag>
npm dist-tag add @rescript/std@<version> <tag>
- Create a release entry for the version tag on the Github Releases page, copying the changes from
CHANGELOG.md
. - 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)"
- Increment the version number in
- 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:
- Go to Actions CI for master
- If you need a specific branch, select a different one to filter to in the GitHub UI.
- Select a specific run (likely the latest)
- Under "Artifacts", download the
npm-packages
artifact and extract it to a folder. - In your repository run:
npm i <path_to_download>npm-packages/rescript-*.tgz
- 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 <[email protected]>
You must use your real name (sorry, no pseudonyms, and no anonymous contributions).