diff --git a/pages/docs/reason-compiler/latest/automatic-interface-generation.mdx b/pages/docs/reason-compiler/latest/automatic-interface-generation.mdx
deleted file mode 100644
index e022f957e..000000000
--- a/pages/docs/reason-compiler/latest/automatic-interface-generation.mdx
+++ /dev/null
@@ -1,29 +0,0 @@
-# Automatic Interface Generation
-
-> Note: this feature currently does not work for new projects!
-
-"Interface files" (`.resi` files) are the "public description" of their corresponding "implementation files" (`.ml`, `.re`), exposed as documentation, and containing nothing but type declarations. Since a file is a module, an interface file is essentially a [module signature](https://reasonml.github.io/docs/en/module.html#signatures).
-
-## Tips & Tricks
-
-You don't have to explicitly write an interface file; by default, one will be inferred from the implementation file (just like how a module's type can be inferred when you hover over it) and **every binding from the file will be exported**. We do encourage that, after you finish iterating on your project:
-
-- Explicitly add interface files to the files meant to be public
-- Add docblock comments on top of each binding to serve as documentation
-- Make some types abstract, and simply don't expose every binding from the interface file
-
-Some types will have to be copy pasted from the implementation file, which gets tedious. This is why we let you **automatically generate interface files**, after which you can tweak whatever you want.
-
-For a file `src/MyUtils.ml`, run:
-
-```sh
-bsc lib/bs/src/MyUtils-MyProject.cmi
-```
-
-Where `MyProject` is your project's namespace. If it's not enabled, it'll be just `MyUtils.cmi`). `.cmi` is the ReScript file that contains some [compiled type info](https://reasonml.github.io/community/faq#compiled-files).
-
-The above command outputs a boilerplate `.mli` interface to stdout (old ml syntax).
-
-_If you don't have `bsc` globally available, use the ones provided locally in `node_modules/bs-platform/lib/bsc.exe`_.
-
-**Note**: the generated boilerplate might contain the strings `"BS-EXTERNAL"` or `"ReScript External"`. This happens when you've used `@bs` externals in your implementation file. It's a temporary flaw; you need to manually turn these `"BS-EXTERNAL"` back into the right `@bs` externals for now. We'll correct this in the future.
diff --git a/pages/docs/reason-compiler/latest/better-data-structures-printing-debug-mode.mdx b/pages/docs/reason-compiler/latest/better-data-structures-printing-debug-mode.mdx
deleted file mode 100644
index dc17bfbc7..000000000
--- a/pages/docs/reason-compiler/latest/better-data-structures-printing-debug-mode.mdx
+++ /dev/null
@@ -1,44 +0,0 @@
-# Better Data Structures Printing Debug Mode
-
-You might have seen that using `Js.log` to print records, variants and others don't print out record field names and variant tags. Record, for example, is compiled into an array (the field names are removed). This is partially for performance, and partially because of [insert excuse here].
-
-To remediate this, we introduce a flag for `bsc` (the BuckleScript compiler), `-bs-g`, that retains record fields names, variant tags, exception names, module names, etc.
-
-<table>
- <thead> <tr><th>Before</th><th>After</th></tr> </thead>
- <tbody>
- <tr>
- <td>
- <img src="/static/img/debugger-before.png" alt="debugger before"/>
- </td>
- <td>
- <img src="/static/img/debugger-after.png" alt="debugger after"/>
- </td>
- </tr>
- </tbody>
-</table>
-
-**Note**: this is for **debugging only**. Please don't forget to undo this for production.
-
-## Usage
-
-- Add `"bsc-flags": ["-bs-g"]` to your `bsconfig.json`.
-- In the BuckleScript/Reason file you'd like to debug, add `[%%debugger.chrome]` at the top \*.
-- If you're on Node.js, run: `node --inspect-brk MyCompiledFile.js` and open this URL in Chrome: `chrome://inspect`.
-- Make sure you've got [Chrome custom formatter enabled](http://www.mattzeunert.com/2016/02/19/custom-chrome-devtools-object-formatters.html).
-- Click on inspect, then step through code as you would usually:
-
-
-
-This custom formatter is still experimental; feel free to contribute to it [here](https://github.com/BuckleScript/bucklescript/blob/master/jscomp/others/belt_Debug.ml)!
-
-**Note**: you need to restart `node` every time your files changes.
-
-**Note**: don't forget to remove `-bs-g` from your `bsconfig.json` for production!
-
-## Tips & Tricks
-
-[Here are other ways](https://nodejs.org/en/docs/guides/debugging-getting-started/#inspector-clients) to debug using node/Chrome.
-
-\* The extension `[%%debugger.chrome]` conditionally turns on the debugger support. Feel free to keep it on at all time; it will not generate any extra garbage code **unless** you have `-bs-g` flag turned on above.
-
diff --git a/pages/docs/reason-compiler/latest/build-advanced.mdx b/pages/docs/reason-compiler/latest/build-advanced.mdx
deleted file mode 100644
index cabf0dcb8..000000000
--- a/pages/docs/reason-compiler/latest/build-advanced.mdx
+++ /dev/null
@@ -1,48 +0,0 @@
-# Build System: Advanced
-
-## Customize Rules (Generators Support)
-
-You might use some pre-processor to generate boilerplate code during development.
-
-**Note**: pre-processors can be classified as two categories:
-
-- System-dependent, which should be delayed until running on user machines.
-- System-independent: lex, yacc, m4, re2c, etc, which can be executed any time.
-
-BS has built-in support for [conditional compilation](conditional-compilation.md), which satisfies the first point. This section is about the second point.
-
-An example, where bsb uses [ocamlyacc](http://caml.inria.fr/pub/docs/manual-ocaml-4.00/manual026.html):
-
-```json
-{
- "generators": [
- {
- "name": "ocamlyacc",
- "command": "ocamlyacc $in"
- }
- ],
- "sources": {
- "dir": "src",
- "generators": [
- {
- "name": "ocamlyacc",
- "edge": ["test.ml", "test.mli", ":", "test.mly"]
- }
- ]
- }
-}
-```
-
-`ocamlyacc` will generate the artifacts `test.ml` and `test.mli` in the same directory than `test.mly`.
-
-**Note**: we highly recommend you to check in the generated files, since this cuts out dependencies like `ocamlyacc` for the end-users.
-
-When developing a project, `bsb` will track the dependencies between `test.ml` and `test.mly` properly. When released as a package, `bsb` will cut such dependency, so that users will only need the generated `test.ml`. To help test such behavior in development mode, users could set it manually:
-
-```json
-{
- "cut-generators": true
-}
-```
-
-This _prevents_ `bsb` from regenerating `test.ml` whenever `test.mly` changes.
diff --git a/pages/docs/reason-compiler/latest/class.mdx b/pages/docs/reason-compiler/latest/class.mdx
deleted file mode 100644
index f6e5700ac..000000000
--- a/pages/docs/reason-compiler/latest/class.mdx
+++ /dev/null
@@ -1,53 +0,0 @@
-# Class Interop
-
-## `new`
-
-Use `bs.new` to emulate e.g. `new Date()`:
-
-```reason
-type t;
-[@bs.new] external createDate : unit => t = "Date";
-
-let date = createDate();
-```
-
-Output:
-
-```js
-var date = new Date();
-```
-
-You can chain `bs.new` and `bs.module` if the JS module you're importing is itself a class:
-
-```reason
-type t;
-[@bs.new] [@bs.module] external book : unit => t = "Book";
-let bookInstance = book();
-```
-
-Output:
-
-```js
-var Book = require("Book");
-var bookInstance = new Book();
-```
-
-## Bind to JS Classes
-
-JS classes are really just JS objects wired up funnily. **In general**, prefer using the previous object section's features to bind to a JS object.
-
-OCaml having classes really helps with modeling JS classes. Just add a `[@bs]` to a class type to turn them into a `Js.t` class:
-
-```reason
-class type _rect =
- [@bs]
- {
- [@bs.set] pub height: int;
- [@bs.set] pub width: int;
- pub draw: unit => unit
- };
-
-type rect = Js.t(_rect);
-```
-
-For `Js.t` classes, methods with arrow types are treated as real methods (automatically annotated with `[@bs.meth]`) while methods with non-arrow types are treated as properties. Adding `bs.set` to those methods will make them mutable, which enables you to set them using `#=` later. Dropping the `bs.set` attribute makes the method/property immutable. Basically like the object section's features.
diff --git a/pages/docs/reason-compiler/latest/compiler-architecture-principles.mdx b/pages/docs/reason-compiler/latest/compiler-architecture-principles.mdx
deleted file mode 100644
index 4243f87fe..000000000
--- a/pages/docs/reason-compiler/latest/compiler-architecture-principles.mdx
+++ /dev/null
@@ -1,68 +0,0 @@
-# Compiler Architecture
-
-ReScript's high level architecture:
-
-```
-Source Language
- |
- | (Reuse OCaml 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)
- | (Patches to pass more information down to Lambda )
- |
-OCaml Lambda IR
- |
- |
- v
-Buckle Lambda IR ------------------+
- | ^ |
- | | 6 Lambda Passes (lam_* files)
- | | Optimization/inlining/dead code elimination
- | \ |
- | \ --------------------------+
- |
- | Self tail call elimination
- | Constant folding + propagation
- V
-JS IR (J.ml) ---------------------+
- | ^ |
- | | 6 JS Passes (js_* files)
- | | Optimization/inlining/dead code elimination
- | \ |
- | \ -------------------------+
- |
- | Smart printer includes scope analysis
- |
- V
-Javascript Code
-```
-
-## Design Decisions
-
-The design of ReScript follows several high-level principles. While those principles might change in the future, they are enforced today and can explain certain technical limitations BS has.
-
-### Lambda Representation
-
-As pictured in the diagram above, ReScript is primarily based on the Lambda representation of the OCaml compiler. While this representation is quite rich, some information is lost from the upstream representation. The patch to the OCaml compiler tries to enrich this representation in a non-intrusive way (see next section).
-
-### Minimal Patch to the OCaml compiler
-
-ReScript requires patches to the OCaml compiler. One of the main reasons is to enrich the Lambda representation so that the generated code is as nice as possible. A design goal is to keep those patches minimal and useful for the OCaml compiler in general so that they can later be integrated.
-
-### Soundness
-
-ReScript preserves the soundness of the OCaml language. Assuming the FFI is correctly implemented, the type safety is preserved.
-
-### Minimal new symbol creation
-
-In order to make the JavaScript generated code as close as possible to the original OCaml core we thrive to introduce as few new symbols as possible.
diff --git a/pages/docs/reason-compiler/latest/concepts-overview.mdx b/pages/docs/reason-compiler/latest/concepts-overview.mdx
deleted file mode 100644
index 2b2c8defb..000000000
--- a/pages/docs/reason-compiler/latest/concepts-overview.mdx
+++ /dev/null
@@ -1,27 +0,0 @@
-# Concepts Overview
-
-Before starting the next few sections, here are a helpful things to know:
-
-## OCaml
-
-This is the backing of BuckleScript. BuckleScript is a fork of OCaml, specifically `v4.02.3` (upgrade impending!). This doc site assumes basic knowledge of OCaml; you can learn OCaml through [Real World OCaml](https://realworldocaml.org/) or, if you're learning Reason anyway, start with the [Reason Manual](/docs/manual/latest/introduction).
-
-**This documentation site will mostly cover just the extra bits we've added to OCaml to enable good JS interoperability**.
-
-## Reason
-
-An alternative syntax for OCaml that's more familiar to JS programmers and reduces the learning overhead a bit. Reason works with OCaml, since apart from the syntax they share most other things. This also means Reason works with BuckleScript. The latter has some first-class support for some other utilities of Reason.
-
-## OPAM
-
-This is OCaml's official package manager. Since BuckleScript uses NPM and Yarn, you won't need OPAM as a beginner. We will mention it for advanced workflows. If you already know OPAM and want to install OCaml toolchains like merlin, you should install those native tool chains under switch 4.06.1
-
-## External/Interop/FFI
-
-These are all jargon for working with BuckleScript \<-> JavaScript.
-
-External: in the context of BuckleScript, one of the primary ways to use a JS value.
-
-Interop: short for "interoperability".
-
-FFI: Foreign Function Interface. The general term for things like "external", "wrapper" and "interop". Basically means calling a value from the other language. Prefer the first two terms.
diff --git a/pages/docs/reason-compiler/latest/conditional-compilation.mdx b/pages/docs/reason-compiler/latest/conditional-compilation.mdx
deleted file mode 100644
index 49a7f7b61..000000000
--- a/pages/docs/reason-compiler/latest/conditional-compilation.mdx
+++ /dev/null
@@ -1,130 +0,0 @@
-# Conditional Compilation
-
-> This only works with the old OCaml syntax.
-
-Sometimes you want to write code that works with different versions of compilers and libraries.
-
-People used to use preprocessors like [C preprocessor](http://tigcc.ticalc.org/doc/cpp.html) for the C family languages. The OCaml community uses several preprocessors: [cppo](https://github.com/mjambon/cppo), [ocp-pp](https://github.com/OCamlPro/typerex-build/tree/master/tools/ocp-pp), camlp4 IFDEF macros, [optcomp](https://github.com/diml/optcomp) and [ppx optcomp](https://github.com/janestreet/ppx_optcomp).
-
-Instead of a preprocessor, ReScript adds language-level static `if` compilation. It's less powerful than other preprocessors since it only supports static `if` (no `#define`, `#undefine`, `#include`), but there are several advantages.
-
-- It’s tiny (only ~500 lines) and highly efficient. Everything can be done in a **single pass**. It's easy to rebuild the pre-processor into a standalone file, with no dependencies on compiler libs, to back-port it to old OCaml compilers.
-- It’s purely functional and type-safe, and cooperates with editor tooling like Merlin.
-
-## Usage
-
-`lwt_unix.mli`
-
-```ocaml
-type open_flag =
- Unix.open_flag =
- | O_RDONLY
- | O_WRONLY
- | O_RDWR
- | O_NONBLOCK
- | O_APPEND
- | O_CREAT
- | O_TRUNC
- | O_EXCL
- | O_NOCTTY
- | O_DSYNC
- | O_SYNC
- | O_RSYNC
-#if OCAML_VERSION =~ ">=3.13" then
- | O_SHARE_DELETE
-#end
-#if OCAML_VERSION =~ ">=4.01" then
- | O_CLOEXEC
-#end
-```
-
-You don't have to add anything to the build to have these work. The compiler `bsc` understands these already.
-
-## Built-in & Custom Variables
-
-See the output of `bsc.exe -bs-list-conditionals`:
-
-```sh
-> bsc.exe -bs-D CUSTOM_A="ghsigh" -bs-list-conditionals
-OCAML_PATCH "BS"
-BS_VERSION "1.2.1"
-OS_TYPE "Unix"
-BS true
-CUSTOM_A "ghsigh"
-WORD_SIZE 64
-OCAML_VERSION "4.02.3+BS"
-BIG_ENDIAN false
-```
-
-Add your custom variable to the mix with `-bs-D MY_VAR="bla"`:
-
-```sh
-> bsc.exe -bs-D MY_VAR="bla" -bs-list-conditionals
-OCAML_PATCH "BS"
-BS_VERSION "1.2.1"
-OS_TYPE "Unix"
-BS true
-MY_VAR="bla"
-...
-```
-
-## Concrete Syntax
-
-```ocaml
-static-if
-| HASH-IF-BOL conditional-expression THEN //
- tokens
-(HASH-ELIF-BOL conditional-expression THEN) *
-(ELSE-BOL tokens)?
-HASH-END-BOL
-
-conditional-expression
-| conditional-expression && conditional-expression
-| conditional-expression || conditional-expression
-| atom-predicate
-
-atom-predicate
-| atom operator atom
-| defined UIDENT
-| undefined UIDENT
-
-operator
-| (= | < | > | <= | >= | =~ )
-
-atom
-| UIDENT | INT | STRING | FLOAT
-```
-
-- IF-BOL means `#IF` should be in the beginning of a line.
-
-## Typing Rules
-
-- type of INT is `int`
-- type of STRING is `string`
-- type of FLOAT is `float`
-- value of UIDENT comes from either built-in values (with documented types) or an environment variable, if it is literally `true`, `false` then it is `bool`, else if it is parsable by `Belt.Int.fromString` then it is of type int, else if it is parsable by `Belt.Float.fromString` then it is float, otherwise it would be string
-- In `lhs operator rhs`, `lhs` and `rhs` are always the same type and return boolean. `=~` is a semantic version operator which requires both sides to be string.
-
-Evaluation rules are obvious. `=~` respect semantic version, for example, the underlying engine
-
-```ocaml
-semver Location.none "1.2.3" "~1.3.0" = false;;
-semver Location.none "1.2.3" "^1.3.0" = true ;;
-semver Location.none "1.2.3" ">1.3.0" = false ;;
-semver Location.none "1.2.3" ">=1.3.0" = false ;;
-semver Location.none "1.2.3" "<1.3.0" = true ;;
-semver Location.none "1.2.3" "<=1.3.0" = true ;;
-semver Location.none "1.2.3" "1.2.3" = true;;
-```
-
-## Tips & Tricks
-
-This is a very small extension to OCaml. It's backward compatible with OCaml except in the following case:
-
-```ocaml
-let f x =
- x
-#elif //
-```
-
-`#elif` at the beginning of a line is interpreted as static `if`. there is no issue with `#if` or `#end`, since they are already keywords.
diff --git a/pages/docs/reason-compiler/latest/difference-from-native-ocaml.mdx b/pages/docs/reason-compiler/latest/difference-from-native-ocaml.mdx
deleted file mode 100644
index 554dc0a3a..000000000
--- a/pages/docs/reason-compiler/latest/difference-from-native-ocaml.mdx
+++ /dev/null
@@ -1,57 +0,0 @@
-# Difference from Native OCaml
-
-This is particularly important when porting an existing OCaml application to JavaScript.
-
-## Custom Data Type
-
-In OCaml, the C FFI allows the user to define a custom data type and customize `caml_compare`, `caml_hash` behavior, etc. This is not available in our backend (since we have no C FFI).
-
-## Physical (in)equality
-
-In general, only use physical equality as an optimization technique; don't rely on its correctness, since it is tightly coupled with the runtime.
-
-## String Char Range
-
-Currently, BuckleScript assumes that the char range is 0-255. The user should be careful when they pass a JavaScript string to the OCaml side. We are working on a solution for this problem.
-
-## Weak Map
-
-OCaml’s weak map is not available in BuckleScript. The weak pointer is replaced by a strict pointer.
-
-## Integers
-
-OCaml has `int`, `int32`, `nativeint` and `int64` types.
-
-- Both `int32` and `int64` in BuckleScript have the exact same semantics as OCaml.
-- `int` in BuckleScript is the same as `int32` while in OCaml it’s platform dependent.
-- `nativeint` is treated as JavaScript float, except for division. For example, `Nativeint.div a b` will be translated into `a / b | 0`.
-
-**Note**: `Nativeint.shift_right_logical x 0` is different from `Int32.shift_right_local x 0`. The former is literally translated into `x >>> 0` (translated into an unsigned int), while the latter is `x | 0`.
-
-## Printf.printf
-
-The Printf.print implementation in BuckleScript requires a newline (`\n`) to trigger the printing. This behavior is not consistent with the buffered behavior of native OCaml. The only potential problem we foresee is that if the program terminates with no newline character, the text will never be printed.
-
-## Obj Module
-
-We do our best to mimic the native compiler, but we have no guarantee and there are differences.
-
-## Hashtbl Hash Algorithm
-
-BuckleScript uses the same algorithm as native OCaml, but the output is different due to the runtime representation of int/int64/int32 and float.
-
-## Marshall Module
-
-Not supported yet.
-
-## Str Module
-
-[Not supported](https://github.com/BuckleScript/bucklescript/issues/879) as it is implemented in C, which is not portable to BuckleScript. Use the [`Js.String`](/docs/manual/latest/api/js/string) module instead which has bindings to the JavaScript [`String`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String) class.
-
-## Sys.argv, Sys.max_array_length, Sys.max_string_length
-
-Command line arguments are always empty. This might be fixed in the future. `Sys.max_array_length` and `Sys.max_string_length` will be the same as `max_int`, but it might be respected.
-
-## Unsupported IO Primitives
-
-Because of the JS environment limitation, `Pervasives.stdin` is not supported but both `Pervasives.stdout` and `Pervasives.stderr` are.
diff --git a/pages/docs/reason-compiler/latest/extended-compiler-options.mdx b/pages/docs/reason-compiler/latest/extended-compiler-options.mdx
deleted file mode 100644
index 3547bac53..000000000
--- a/pages/docs/reason-compiler/latest/extended-compiler-options.mdx
+++ /dev/null
@@ -1,116 +0,0 @@
-# Extended Compiler Options
-
-**Note**: this section is only for people who want roll their own build system instead of using the recommended build system, `bsb`. This also provides some tips for contributors who debug the compiler.
-
-ReScript inherits the command line arguments of the [OCaml compiler](http://caml.inria.fr/pub/docs/manual-ocaml/comp.html). It also adds several BS-specific flags. Run `bsc -help` to see the list.
-
-All these flags can be passed into the `bsc-flags` section of `bsb` (though some of them don't make sense to be passed).
-
-**Note** also that this section isn't kept very up-to-date. Contributions welcome!
-
-## -bs-main (single directory build)
-
-```sh
-bsc -bs-main Main
-```
-
-`bsc` will build module `Main` and all its dependencies. When it finishes, it'll run `node main.js`.
-
-```sh
-bsc -c -bs-main Main
-```
-
-Same as above, but will not run `node`.
-
-## -bs-files
-
-So that you can do
-
-```sh
-bsc -c -bs-files *.ml *.mli
-```
-
-the compiler will sort the order of input files before starting compilation.
-
-ReScript supports two compilation modes: script mode and package mode. In package mode, you have to provide `package.json` on top and set the options `-bs-package-name`, `-bs-package-output`. In script mode, such flags are not needed.
-
-## -bs-package-name
-
-The name of your project. It's recommended to use the same `name` than the one in `package.json`.
-
-## -bs-package-output
-
-Configure the output module system. The format is `module_system:output/path/relative/to/package.json`.
-
-Currently supported systesms are: `commonjs`, `amdjs` and `es6`.
-
-For example, when you want to use the `es6` module system:
-
-```sh
-bsc -bs-package-name your_package -bs-package-output es6:lib/es6 -c xx.ml
-```
-
-**Note**: you can supply multiple `-bs-package-output` at once. For example:
-
-```sh
-bsc -bs-package-name name -bs-package-output commonjs:lib/js -bs-package-output amdjs:lib/amdjs -c x.ml
-```
-
-It'll generate `x.js` in `lib/js` as a commonjs module, `lib/amdjs` as an amdjs module at the same time.
-
-You would then need a bundler for the different module systems: webpack supports `commonjs` and `amdjs`, rollup supports es6, while google closure compiler supports all.
-
-## -bs-no-warn-ffi-type
-
-Turn off warnings on FFI type declarations.
-
-## -bs-eval
-
-Example:
-
-```sh
-> bsc -dparsetree -drawlambda -bs-eval 'Js.log "hello"'
-
-[
- structure_item (//toplevel//[1,0+0]..[1,0+14])
- Pstr_eval
- expression (//toplevel//[1,0+0]..[1,0+14])
- Pexp_apply
- expression (//toplevel//[1,0+0]..[1,0+6])
- Pexp_ident "Js.log" (//toplevel//[1,0+0]..[1,0+6])
- [
- <label> ""
- expression (//toplevel//[1,0+7]..[1,0+14])
- Pexp_constant Const_string("hello",None)
- ]
-]
-
-(setglobal Bs_internal_eval! (seq (log "hello") (makeblock 0)))
-// Generated by ReScript VERSION 2.1.0, PLEASE EDIT WITH CARE
-'use strict';
-
-
-console.log("hello");
-
-/* Not a pure module */
-```
-
-In conjunction with `-bs-eval`: the first block is the output of `-dparsetree`, the second is from `-drawlambda`.
-
-`-bs-eval` doesn't create intermediate file. Useful for learning or troubleshooting.
-
-## -bs-no-builtin-ppx-ml, -bs-no-builtin-ppx-mli
-
-If you don't use any BS-specific annotations, you can explicitly turn it off. Another use-case is to use `-ppx` explicitly as below:
-
-```sh
-bsc -c -ppx bsppx.exe -bs-no-builtin-ppx-ml c.ml
-```
-
-## -bs-no-version-header
-
-Don’t print BS version at the beginning of each JS file.
-
-## -bs-g (Experimental, since @3.1.0)
-
-See [Better Data Structures Printing (Debug Mode)](./better-data-structures-printing-debug-mode.md).
diff --git a/pages/docs/reason-compiler/latest/handling-js-naming-collisions.mdx b/pages/docs/reason-compiler/latest/handling-js-naming-collisions.mdx
deleted file mode 100644
index 2b97ad1be..000000000
--- a/pages/docs/reason-compiler/latest/handling-js-naming-collisions.mdx
+++ /dev/null
@@ -1,109 +0,0 @@
-# Handling JS Naming Collisions
-
-JavaScript has different naming conventions and has only very few limitations when it comes to naming variables, classes, functions, JS object attributes etc.
-
-Reason on the contrary has more restrictive naming rules which need to be considered whenever you define a type, function, value, module, record attribute or similar. Here are a few typical naming restrictions which cause trouble with JS:
-- Every name needs to start with a lowercase letter (uppercase is reserved for module names)
-- For the same reason, names can't be all caps (very common for JS constants: `const MY_CONSTANT = "my_constant"`)
-- It's not possible to use [reserved keywords](/docs/manual/latest/reserved-keywords) for names
-- Labeled arguments (for defining JSX attributes) can't be named after keywords and can't start with an uppercase letter
-- etc.
-
-Of course, when doing interop, we still want to be able to map to the JS equivalent (preferably without any runtime overhead). In this section we describe some common scenarios on how to gracefully handle naming collisions.
-
-
-## Using reserved keywords as JSX props
-
-Many React components have a prop named `type` in JavaScript:
-
-```js
-/* this won't work in Reason since `type` is a reserved keyword! */
-<Component type="title" />
-```
-
-If you're using a React component with a reserved keyword as a prop name, then simply prepend a underscore (so that it's a valid Reason name):
-
-```reason
-/* This works because `_type` is not a reserved keyword */
-<Component _type="title" />
-```
-
-The Reason compiler will remove the leading underscore when outputting JavaScript (so the JavaScript will have `<Component type="POST" />`).
-
-The removal of the `_` is called "Name mangling". The ruleset for this behavior is discussed [further down below](#special-name-mangling-rules-for-js-object-attribute-names).
-
-## Accessing JavaScript object attributes that start with a capital letter
-
-Capital letters in Reason are used exclusively for module names, like `String` and `Belt`, and they cannot be used as record field names like in JavaScript.
-
-```js
-const payload = {
- PostTitle: "Welcome to Reason",
-};
-
-/* this won't work in Reason since `PostTitle` is capitalized, so `paylod.PostTitle` would break */
-const title = payload.PostTitle;
-```
-
-In this case, when writing bindings to the JavaScript object, you can use the `[@bs.as "whatever-name-you-want-in-javascript"]` to tell the compiler exactly what the JavaScript attribute name should be in the compiled output:
-
-```reason
-type payload {
- [@bs.as "PostTitle"]
- postTitle: string
-}
-
-let payload = {
- postTitle: "Welcome to Reason"
-}
-
-/* Reason is happy since we're using the valid `postTitle` field name */
-let title = payload.postTitle;
-```
-
-The code above will be translated to following JS:
-
-```js
-/* The correct capitalized field name is output in the JavaScript! */
-var title = payload.PostTitle;
-```
-
-## Accessing reserved keywords as JavaScript object attribute names
-
-Just like accessing attributes that start with a capital letter, we can use `[@bs.as "the-reserved-keyword-that-javascript-wants"]`. It's customary to append an underscore (unlike the JSX case, where we *prepend* the underscore) to the reserved keyword name:
-
-```reason
-type payload {
- [@bs.as "type"]
- type_: string
-}
-
-let payload = {
- type_: "Documentation"
-}
-
-/* Reason is happy since we're using the valid `type_` field name */
-let payloadType = payload.type_;
-```
-
-The code above will be translated to following JS:
-
-```js
-/* The reason compiler has correctly ouput `payload.type` even though *we* called the field `type_` */
-var payloadType = payload.type;
-```
-
-## Special name mangling rules for JS object attribute names
-
-> **Note:** This is special behavior partly implemented in the Reason syntax, partly in the BuckleScript compiler. This section is mostly useful for understanding how JS object attributes and labeled arguments of ReasonReact components are compiled.
-
-> **Another Note:** A JS object type is a structurally typed entity with special compilation behavior, so they act differently than records or plain Reason objects. They are encoded as `Js.t({...})` types, more details about that feature can be found [here](http://localhost:3000/docs/reason-compiler/latest/object-2#actual-solution).
->
-> Labeled arguments used in `[@react.component]` functions (like `let make = (~name: string, ~age: int) => React.element`) are transformed into the `Js.t` representation (e.g. `let make = Js.t({."name": string, "age": int}) => React.element`), so they follow the same ruleset.
-
-When accessing a JavaScript object field in a structural way (e.g. `myJsObject##some`), the following rules apply:
-
-1. A single _leading_ underscore will be *dropped* from the output: `myJsObject##_type` => `myJsObject.type`
-1. Two (or more) _leading_ underscores will be *kept* in the output: `myJsObject##__type` => `myJsObject.__type`
-1. There is _no way_ to access e.g. `myJsObject##_type` structurally - use records and `[@bs.as "_type"]` instead
-1. The _final trailing_ double underscores (and anything following them) will be dropped from the output: `myJsObject##this_is_kept__this_is_omitted` => `myJsObject.this_is_kept`
diff --git a/pages/docs/reason-compiler/latest/interop-misc.mdx b/pages/docs/reason-compiler/latest/interop-misc.mdx
deleted file mode 100644
index 03ff33c6f..000000000
--- a/pages/docs/reason-compiler/latest/interop-misc.mdx
+++ /dev/null
@@ -1,39 +0,0 @@
-# Interop Miscellaneous
-
-## Composing `bs` Attributes
-
-As you might have guessed, most `bs.*` attributes can be used together. Here's an extreme example:
-
-Note that `bs.splice` was renamed to `bs.variadic` after version 4.08
-
-```reason
-[@bs.val] [@bs.scope "global"] [@bs.variadic]
-external draw : ([@bs.as "dog"] _, array(int)) => unit = "draw";
-
-draw([|1, 2|]);
-```
-
-Output:
-
-```js
-global.draw("dog", 1, 2);
-```
-
-## Safe External Data Handling
-
-In some cases, the data could either come from JS or BS; it's very hard to give precise type information because of this. For example, for an external promise whose creation could come from the JS API, its failed value caused by `Promise.reject` could be of any shape.
-
-BuckleScript provides a solution, `bs.open`, to filter out OCaml structured exception data from the mixed data source. It preserves type safety while allowing you to deal with mixed source. It makes use of OCaml’s extensible variant, so that users can mix values of type `exn` with JS data.
-
-```reason
-let handleData = [@bs.open] (
- fun
- | Invalid_argument(_) => 0
- | Not_found => 1
- | Sys_error(_) => 2
-);
-
-/* handleData is 'a => option(int) */
-```
-
-For any input source, as long as it matches the exception pattern (nested pattern match supported), the matched value is returned, otherwise return `None`.
diff --git a/pages/docs/reason-compiler/latest/nodejs-special-variables.mdx b/pages/docs/reason-compiler/latest/nodejs-special-variables.mdx
deleted file mode 100644
index d5575d1b3..000000000
--- a/pages/docs/reason-compiler/latest/nodejs-special-variables.mdx
+++ /dev/null
@@ -1,12 +0,0 @@
-# NodeJS Special Variables
-
-NodeJS has several file local variables: `__dirname`, `__filename`, `_module`, and `require`. Their semantics are more like macros instead of functions.
-
-`bs.node` exposes support for these.
-
-```reason
-let dirname: option(string) = [%bs.node __dirname];
-let filename: option(string) = [%bs.node __filename];
-let _module: option(Node.node_module) = [%bs.node _module];
-let require: option(Node.node_require) = [%bs.node require];
-```
diff --git a/pages/docs/reason-compiler/latest/object-2.mdx b/pages/docs/reason-compiler/latest/object-2.mdx
deleted file mode 100644
index 15a22db9e..000000000
--- a/pages/docs/reason-compiler/latest/object-2.mdx
+++ /dev/null
@@ -1,161 +0,0 @@
-# Object 2
-
-There's an alternative of binding to JavaScript objects, if the previous section's `bs.deriving abstract` doesn't suit your needs:
-
-- You don't want to declare a type beforehand
-- You want your object to be "structural", e.g. your function wants to accept "any object with the field `age`, not just a particular object whose type definition is declared above".
-
-> Reminder of the above distinction of record vs object [here](/docs/manual/latest/record#record-types-are-found-by-field-name).
-
-This section describes how BuckleScript uses OCaml's object facility to achieve this other way of binding and compiling to JavaScript objects.
-
-## Pitfall
-
-First, note that we **cannot** use the ordinary OCaml/Reason object type, like this:
-
-```reason
-type person = {
- .
- name: string,
- age: int,
- job: string
-};
-```
-
-You can still use this feature, but this OCaml/Reason object type does **not** compile to a clean JavaScript object! Unfortunately, this is because OCaml/Reason objects work a bit too differently from JS objects.
-
-## Actual Solution
-
-BuckleScript wraps the regular OCaml/Reason object type with `Js.t`, in order to control and track a **subset** of operations and types that we know would compile cleanly to JavaScript. This is how it looks like:
-
-```reason
-type person = Js.t({
- .
- name: string,
- age: int,
- job: string
-});
-
-[@bs.val] external john : person = "john";
-```
-
-**From now on**, we'll call the BuckleScript interop object "`Js.t` object", to disambiguate it with normal object and JS object.
-
-Because object types are used often, Reason gives it a nicer sugar.
-Writing `{. "name": string}` is syntactic sugar for `Js.t({. name: string})`.
-Note that the double quotes around the field name `name` are necessary.
-Without it, this expression becomes an OCaml object, which you probably don't want to if you're targeting JavaScript.
-
-### Accessors
-
-#### Read
-
-To access a field, use `##`: `let johnName = john##name`.
-
-#### Write
-
-To modify a field, you need to first mark a field as mutable. By default, the `Js.t` object type is immutable.
-
-```reason
-type person = {. [@bs.set] "age": int};
-[@bs.val] external john : person = "john";
-
-john##age #= 99;
-```
-
-**Note**: you can't use dynamic/computed keys in this paradigm.
-
-#### Call
-
-To call a method of a field, mark the function signature as `[@bs.meth]`:
-
-```reason
-type person = {. [@bs.meth] "say": (string, string) => unit};
-[@bs.val] external john : person = "john";
-
-john##say("hey", "jude");
-```
-
-**Why `[bs.meth]`**? Why not just call it directly? A JS object might carry around a reference to `this`, and infamously, what `this` points to can change. OCaml/BuckleScript functions are curried by default; this means that if you intentionally curry `say`, by the time you fully apply it, the `this` context could be wrong:
-
-```reason
-/* wrong */
-let talkTo = john##say("hey");
-
-let jude = talkTo("jude");
-let paul = talkTo("paul");
-```
-
-To ensure that folks don't accidentally curry a JavaScript method, we track every method call using `##` to make sure it's fully applied _immediately_. Under the hood, we effectively turn a function-looking call into a special `bs.meth` call (it only _looks_ like a function). Annotating the type definition of `say` with `bs.meth` completes this check.
-
-### Creation
-
-#### Literal
-
-You can use `[%bs.obj putAnOCamlRecordHere]` DSL to create a `Js.t` object:
-
-```reason
-let bucklescript = [%bs.obj {
- info: {author: "Bob"}
-}];
-
-let name = bucklescript##info##author;
-```
-
-Because object values are used often, Reason gives it a nicer sugar: `{"foo": 1}`, which desugars to: `[%bs.obj {foo: 1}]`.
-
-**Note**: there's no syntax sugar for creating an empty object in OCaml nor Reason (aka this doesn't work: `[%bs.obj {}]`. Please use `Js.Obj.empty()` for that purpose.
-
-The created object will have an inferred type, no type declaration needed! The above example will infer as:
-
-**Note**: since the value has its type inferred, **don't** accidentally do this:
-
-```reason
-type person = {. "age": int};
-let jane = {"age": "hi"};
-```
-
-See what went wrong here? We've declared a `person` type, but `jane` is inferred as its own type, so `person` is ignored and no error happens! To give `jane` an explicit type, simply annotate it: `let jane: person = ...`. This will then error correctly.
-
-#### Function
-
-You can declare an external function that, when called, will evaluate to a `Js.t` object with fields corresponding to the function's parameter labels. This is very handy because you can make some of those labelled parameters _optional_ and if you don't pass them in, the output object _won't include_ the corresponding fields. Thus you can use it to dynamically create objects with the subset of fields you need at runtime.
-
-For example, suppose you need a JavaScript object like this:
-
-```js
-var homeRoute = {
- method: "GET",
- path: "/",
- action: () => console.log("Home"),
- // options: ...
-};
-```
-
-But only the first three fields are required; the `options` field is optional. You can declare the binding function like so:
-
-```reason
-[@bs.obj] external route: (
- ~_method:string,
- ~path:string,
- ~action:(list(string) => unit),
- ~options:Js.t({..})=?,
- unit
-) => _ = "";
-```
-
-**Note**: the ` = ""` part at the end is just a dummy placeholder, due to syntactic limitations. It serves no purpose currently.
-
-This function has four labelled parameters (the fourth one optional), one unlabelled parameter at the end (which we mandate for functions with [optional parameters](/docs/manual/latest/function.html#optional-labeled-arguments)), and one parameter (`_method`) that requires an underscore prefix to avoid confusion with the OCaml/Reason keyword `method`.
-
-Also of interest is the return type: `_`, which tells BuckleScript to automatically infer the full type of the `Js.t` object, sparing you the hassle of writing down the type manually!
-
-The function is called like so:
-
-```reason
-let homeRoute = route(~_method="GET", ~path="/", ~action=(_ => Js.log("Home")), ());
-```
-
-This generates the desired JavaScript object–but you'll notice that the `options` parameter was left out. As expected, the generated object won't include the `options` field.
-
-**Note** that for more type-safety you'll probably want to [constrain](/docs/manual/latest/bind-to-js-function#constrain-arguments-better) the `_method` parameter type to only the acceptable values.
diff --git a/pages/docs/reason-compiler/latest/upgrade-to-v7.mdx b/pages/docs/reason-compiler/latest/upgrade-to-v7.mdx
deleted file mode 100644
index 4af1682bc..000000000
--- a/pages/docs/reason-compiler/latest/upgrade-to-v7.mdx
+++ /dev/null
@@ -1,209 +0,0 @@
-# Upgrade Guide to v7
-
-If you have been using BuckleScript for the last couple of years, you probably
-noticed that upgrading to the newest version has always been a seamless
-experience without any breaking changes or performance loss. That's because the
-BuckleScript team puts a lot of effort in making sure users can upgrade as
-soon as possible without any changes in their workflow.
-
-That said, this time with the v7 release, there have been some fundamental
-compiler changes, which means that upgrades will involve a few more installation
-steps than usual (depending on your project setup). Luckily, the upgrade should
-still be straight forward and easy to do.
-
-This guide will highlight some of the changes and give you a list of
-instructions to upgrade your BuckleScript projects.
-
-> **Note:** You probably noticed that the version number jumped from v5 to v7.
-> The v6 version was used for the transition phase, so if you are using v6 right
-> now, just upgrade to `bs-platform@7` and you are good to go.
-
-## A Quick Look under the Hood
-
-BuckleScript v7 (and v6) changed the underlying OCaml version from `4.02.3` (BS
-v5) to `4.06.1`. Usually this shouldn't impact any existing codebases, unless
-they are using PPXes or other meta programming facilities. Simply explained,
-PPXes rely on the data representation of the OCaml / Reason syntax (AST), so if
-you are using a tool such as `graphql_ppx` (which has usually been compiled
-natively with a `4.02.3` OCaml version) you will get a compatibility error when
-used with BuckleScript v7.
-
-Luckily during the transition phase between v5 and v7 (which has been an ongoing
-process for for several months), the community has been [coordinating
-efforts](https://github.com/BuckleScript/bucklescript/issues/3914) to upgrade
-and release commonly used tools to BS v7 compatible compile artifacts. You will
-find all installation instructions in this guide as well.
-
-
-### BS Version Overview / Features
-
-- *BS 5.x and below*: based on OCaml 4.02.3
-- *BS 6.x and above*: based on OCaml 4.06.1 (transition version: if in use, upgrade to v7 now)
-- *BS 7.x and above*: based on OCaml 4.06.1 (stops 4.02.3 support)
- - Adds [`Inline
- Records`](https://caml.inria.fr/pub/docs/manual-ocaml/inlinerecords.html)
- support (introduced with `4.03`)
- - Adds the `Records-as-Objects` feature, which makes BS compile record type
- values into JS objects instead of nested arrays (see blog [post 1](//bucklescript.github.io/blog/2019/11/18/whats-new-in-7)
- and [post 2](//bucklescript.github.io/blog/2019/12/27/whats-new-in-7-cont))
- - Ships with `refmt` version `3.5.1` with greatly improved syntax error messages (codename `reerror`)
-
-The biggest upside of upgrading to BS v7, beside enjoying newer language
-features, is that we will finally be able to deprecate underlying OCaml
-`4.02.3` code, which will make maintenance way easier (lots of code / processes
-can be removed and simplified). Also the OCaml community will greatly benefit
-from this change, since a lot of OCaml libraries still have to support a minimum
-OCaml version of `4.02.3` just for BuckleScript \<= v5 compatibility.
-
-> We recommend upgrading to BS v7 as soon as possible. Your Reason code will
-> still work as expected, you'll only need to upgrade your native tools to make
-> everything behave correctly.
-
-Please support us moving forward and help us by providing bug reports in case
-you have any issues.
-
-## How to upgrade to v7
-
-### Dependencies
-
-**Note:** During the migration phase, some projects / repositories have changed
-owners or GitHub organizations to make it easier for us to upgrade build
-artifacts in the future. If you are using a PPX we are not aware of, please [let us
-know in this issue](https://github.com/BuckleScript/bucklescript/issues/3914).
-
-#### Upgrade your bs-platform dependency:
-
-- `npm install bs-platform@7 --dev`
-
-#### Upgrade any PPX dependencies you're using:
-
-[`graphql_ppx`](https://github.com/mhallin/graphql_ppx) ->
-[`graphql_ppx_re`](https://github.com/baransu/graphql_ppx_re):
- - Remove the [deprecated `graphql_ppx` (by
- mhallin)](https://github.com/mhallin/graphql_ppx): `npm remove
- graphql_ppx`
- - Add the new one: `npm install @baransu/graphql_ppx_re --save-dev`
- - Update your `ppx-flags`: `"ppx-flags": ["@baransu/graphql_ppx_re/ppx6"]`
-
-[`gentype`](https://github.com/cristianoc/genType):
-- `npm install gentype@3 --save-dev`
-
-[`decco`](https://github.com/reasonml-labs/decco):
-- `npm install decco@1 --save-dev`
-
-[`bs-let`](https://github.com/reasonml-labs/bs-let):
-- `npm install --save-dev bs-let`
-- Update your `ppx-flags`: `"ppx-flags": ["bs-let/ppx"]`
-
-[`bs-emotion-ppx`](https://github.com/ahrefs/bs-emotion):
-- `npm install bs-emotion-ppx@1 --save-dev`
-- Update your `ppx-flags`: `"ppx-flags": ["@ahrefs/bs-emotion-ppx/bin/bs-emotion-ppx"]`
-
-[`bs-log`](https://github.com/MinimaHQ/bs-log)
-- Currently WIP and [not done
-yet](https://github.com/MinimaHQ/bs-log/issues/10)
-
-[`ppx_bs_css`](https://github.com/astrada/ppx_bs_css):
-- No upgrade activity yet, please [let us
-know](https://github.com/BuckleScript/bucklescript/issues/3914) if you are
- using it!
-
-#### Clean & Rebuild your project:
-- `npx bsb -clean-world`
-- `npx bsb -make-world`
-- Your project should now be built and working correctly
-
-#### Fix specific warnings:
-- `BuckleScript warning: isWebUri : the external name is inferred from val
- name is unsafe from refactoring when changing value name`
- - This means that you have `external` bindings ending with `= "";`
- (which will automatically take the name of the binding itself), you
- now need to be explicit with the name. Example:
- ```reason
- /* Before (warning) */
- [@bs.module "valid-url"]
- external isWebUri: string => option(string) = "";
-
- /* After (fixed the warning) */
- [@bs.module "valid-url"]
- external isWebUri: string => option(string) = "isWebUri";
- ```
-- Don't forget to rebuild your project again
-
-#### Commit your changes:
-- Your `.bs.js` files will very likely change, make sure to commit
- everything to have a clean BS upgrade commit
-
-
-**Note:** Since this upgrade will change the internal data representation of
-records to JS objects, make sure you are not having any Reason code relying on
-the previous record-as-array representation. This is a quick reminder that it is
-generally discouraged to rely on internal data structures.
-
-### Editor extensions
-
-- [`reason-vscode / reason-language-server`](https://github.com/jaredly/reason-language-server):
- Should just work, especially when upgraded to the newest version
-- [`merlin`](https://github.com/ocaml/merlin): Make sure your `ocamlmerlin` binary is
- compiled for `4.06.1` and correctly set in your PATH, other than that it should just work
-- [`reasonml-idea-plugin`](https://github.com/reasonml-editor/reasonml-idea-plugin): Upgrade to version `v0.76` or above
-
-
-## How to upgrade PPXes (for tool maintainers)
-
-### Step 1: Upgrade build dependencies
-
-We recommend using [esy](https://esy.sh) for building your native project, so
-all instructions are based on the `esy` workflows. Mostly it's about setting the
-OCaml version to 4.06 and rebuild the project accordingly (e.g. in your `package.json`):
-
-```json
-"devDependencies": {
- "ocaml": "~4.6.1000",
- "@opam/dune": "*",
-}
-```
-
-If you are using `migrate-parse-tree`, you might want to drop any AST upgrades
-from 4.02 -> 4.06 etc, making the native binary more lightweight.
-
-**Tip:** If you still want to maintain a `4.02.3` based version (for legacy
-reasons), you can alternatively create a `esy.json` / `esy-406.json` file and
-use `esy's` [sandboxing
-feature](https://esy.sh/docs/en/multiple-sandboxes.html#configure-multiple-sandboxes).
-
-We know that these instructions are very rough, many projects use different
-configurations. To give you some inspiration on how to tackle an upgrade, here
-is a list of migrations / project setups you might find useful:
-
-- `bs-emotion-ppx`: [Full migration diff by anmonteiro](https://github.com/ahrefs/bs-emotion/commit/d93f35754d2ba3000d5ffa9fe17ae158da6dfc38)
-- `graphql_ppx_re`: [package.json with 4.06
- support](https://github.com/baransu/graphql_ppx_re/blob/master/esy.json) //
- [402.json for esy
- sandbox](https://github.com/baransu/graphql_ppx_re/blob/master/402.json)
-- `decco`: [package.json for 4.06](https://github.com/reasonml-labs/decco/blob/master/ppx_src/package.json)
-
-### Step 2: Release artifacts and add a proper Note in the README
-
-Make sure to release the newly built binary on npm and make clear which PPX versions are compatible with BS6 / BS5 etc.
-For example, this is how `gentype` does it:
-
-```
-bs-platform 7.0.0 or higher: use genType 3.2.0 or higher.
-bs-platform 6.2.0 or higher: use genType 3.0.0 or higher.
-bs-platform 5.2.0 or higher: use genType 2.40.0 or higher.
-bs-platform 5.0.x and 5.1.x: use genType 2.17.0 or higher.
-```
-
-
-## Conclusion
-
-We are really excited for the upcoming future of BuckleScript. The v7 release
-will make JS interop considerably easier while being completely compatible with
-existing codebases.
-
-If you are experiencing any installation / upgrade issues, please be sure to
-either check the BuckleScript [issue
-tracker](https://github.com/bucklescript/bucklescript/issues), or drop us a
-message in [Discord](https://discord.gg/reasonml).
-