|
| 1 | +--- |
| 2 | +author: hongbo |
| 3 | +date: "2020-12-07" |
| 4 | +previewImg: |
| 5 | +category: compiler |
| 6 | +title: ReScript 8.4 |
| 7 | +description: | |
| 8 | +--- |
| 9 | + |
| 10 | +## Introduction |
| 11 | + |
| 12 | +ReScript is a soundly typed language with an optimizing compiler focused on the JS platform. |
| 13 | +It's focused on type safety, performance and JS interop. It used to be called BuckleScript. |
| 14 | + |
| 15 | +[[email protected]](https://www.npmjs.com/package/bs-platform/v/8.4.2) is now available for testing, you can try it via |
| 16 | + |
| 17 | +``` |
| 18 | + |
| 19 | +``` |
| 20 | + |
| 21 | +The changes are listed [here](https://github.com/rescript-lang/rescript-compiler/blob/master/Changes.md#841). |
| 22 | + |
| 23 | +We will go through some highlighted changes. |
| 24 | + |
| 25 | +### The integrity of `bsb -make-world` |
| 26 | + |
| 27 | +When we introduced `bsb` as a build system around four years ago, we made the assumption that dependencies are immutable, |
| 28 | +so that once it's built for the first time, we don't need to rebuild it any more. The integrity of `bsb -make-world` will be broken |
| 29 | +when the assumption does not hold. |
| 30 | + |
| 31 | +In this release, we fix the integrity of `bsb -make-world` which allows user to changes the dependencies. |
| 32 | +The fix is well implementend that people who don't do such modifications will not pay for it. |
| 33 | + |
| 34 | +This is one of the highest desired feature request based on the |
| 35 | +[user feedback](https://github.com/rescript-lang/rescript-compiler/issues/4361#issuecomment-739538789), so we will expand a bit here why it is tricky |
| 36 | +to implement it without compromising performance. |
| 37 | + |
| 38 | +In ReScript compilation scheme, dependencies as packages are treated as a blackbox, |
| 39 | +changes of dependencies should be *transitive*. The is due to that we have cross module |
| 40 | +optimizations and the binary interface itself is a hash of its dependencies. |
| 41 | +So for a package dependency chain: A -> B -> C, if A changes and B does not change, C still needs get rebuilt. |
| 42 | +Because the intermediate output of B may still change due to the change of A. |
| 43 | +To make things worse, each package comes with an installation process which is a shell script, so re-installation will make the |
| 44 | +package look like freshly built. |
| 45 | + |
| 46 | +In this release, we track the installation in the build graph as well, and we calculate the hash of the installation of dependencies and put it in the |
| 47 | +dependent's command line flags for building binary artifacts. Such strategy benefits in such aspects: |
| 48 | + |
| 49 | +- The calculation of the hash of installation is almost free since it is just one stat, we don't need track all dependencies' artifacts. |
| 50 | +- The introducion of such hashing does not appear in parsing, so that the changes of dependencies will never trigger re-parsing. |
| 51 | +- Once the package installation is a nop, the transitive rebuild graph will be cut off so that we can save some unneeded rebuild. |
| 52 | +- When people make changes to the depdendencies, if such changes don't change the package interface, it will not trigger the build of its dependents. |
| 53 | + |
| 54 | +### Introducing `pinned-dependencies` |
| 55 | + |
| 56 | +To make `bsb -make-world` more pratical, we also introduce a new concept called: `pinned-dependencies`. |
| 57 | +In general, packages are classified as three categories: |
| 58 | + |
| 59 | +- toplevel |
| 60 | + - warnings reported |
| 61 | + - warn-error respected |
| 62 | + - build dev dependency |
| 63 | + - run custom rules |
| 64 | + - package-specs like es6/commonjs overrides all its dependencies |
| 65 | +- pinned dependencies |
| 66 | + - warnings reported |
| 67 | + - warn-error respected |
| 68 | + - build dev dependency |
| 69 | + - run custom rules |
| 70 | +- normal dependencies |
| 71 | + - warnings, warn-error ignored |
| 72 | + - ignore dev directories |
| 73 | + - ignore custom generator rules |
| 74 | + |
| 75 | +Previously, we only had `toplevel` and `normal dependencies`, by introducing `pinned-dependencies`, |
| 76 | +such package will be built mostly like `toplevel` packages. |
| 77 | + |
| 78 | +The usage is quite simple, add `pinned-dependencies` in the toplevel package's `bsconfig.json`. |
| 79 | +Note such field only make sense in toplevel's configuration. |
| 80 | + |
| 81 | + |
| 82 | +### More robust hanlding of removal of staled output |
| 83 | + |
| 84 | +When people delete or rename rescript files, it will introduce dangling staled output, for example, renaming `src/A.res` |
| 85 | +into `src/B.res` will bring `src/A.cmi` (and more intemediate outputs) stale. This is worse than it sounds like, suppose you have a |
| 86 | +local `src/List.res` which shadows the stdlib's List. Now we remove it, it will introduce stale `List.cmi` file, without the proper removal |
| 87 | +of such stale outptu, such stale `List.cmi` file will break the integrity of the build. |
| 88 | + |
| 89 | +In this release, we introduced a more robust algorithm that will always remove stale output before the build so |
| 90 | +that such integrity is not broken. |
| 91 | + |
| 92 | +Last but not the least, we continue improving the readability, debuggability of the [generated output](https://github.com/rescript-lang/rescript-compiler/pull/4858) : ) |
| 93 | + |
| 94 | +Happy Hacking! -- Hongbo Zhang |
0 commit comments