Upgrading from bs-platform@9 to rescript@9.1.3: Unbound module Marshal (bisect_ppx?)

Hey, we recently tried upgrading from bs-platform to rescript (yay) but unfortunately during cleaning and building, we received the following error:

rescript: [1/3] src/common/bisect_common-Bisect.cmj
FAILED: src/common/bisect_common-Bisect.cmj
File "/Users/peter/Projects/draftbit/builder/node_modules/bisect_ppx/src/common/bisect_common.ml", line 183, characters 3-20:
Error: Unbound module Marshal
FAILED: cannot make progress due to previous errors.
Failure: /Users/peter/Projects/draftbit/builder/node_modules/rescript/darwin/ninja.exe
Location: /Users/peter/Projects/draftbit/builder/node_modules/bisect_ppx/lib/bs
error Command failed with exit code 2.

It sounds like it has something to do with bisect_ppx. That being said, I’m not sure what this means for us moving forward. Any help would be great, thanks!

We rely on the following bs-dependencies:


and the following ppx flags:

  "ppx-flags": [
      "-path ./src/waterloo/tailwind.css"
    ["@baransu/graphql_ppx_re/ppx6", "-apollo-mode"],

See this:

It seems it is relude-parse depending on bastset which depends bisect-ppx.

It is not a breaking change from rescript point of view, however, ppx could introduce meta-level dependencies, it generates unused code which uses Marshal, but you need to make it compile even you never use it. bisect-ppx is mostly a code instrumentation tool which should be only enabled in CI.

In retrospect, it is a mistake to introduce ppx in rescript, it makes upgrade so painful, any innocent change could potentially be a breaking change.

Edit: if you don’t mind vendoring, you can comment bisect-ppx relevant fields in bastet, it should just work.

I don’t want to comment on the old discussion about Marshall module. If something like this happens again, I would consider creating forks of the key widely used dependencies that will break before releasing the new compiler version, so that each industrial user doesn’t have to discover the breakage individually.

how does that work ? If you fork that library but can not publish it under the same name, right?

Maybe a temporary organization like “@rescript-compat/” and have the libraries exist there?

1 Like

Have @rescript-compat seems to be a good idea
but the work seems to be not small, we will discuss about this and see how we can move forward.
Take the reported case here for example,
a -> b -> c -> d
If we fix d, we also need have c pointed to @rescirpt-compat/d and a, b updated as well.

Thanks everyone! I’ll give this a shot and post updates if something doesn’t work out