Proposed plan for building all stdlibs with rewatch and integrating Core about rescript-compiler HOT 8 OPEN

I think the resulting standard library packages could then even be published as separate npm packages (see #6183) independent of a v12 compiler release. They could be used/tested in any ReScript project that sets the -nostdlib compiler option and adds them as dependencies.

from rescript-compiler.

@zth @cristianoc @jfrolich @rolandpeelen what do you think?

from rescript-compiler.

I think it's probably easier to get everything compiled the same way using rewatch in the compiler repo, and refactor from there. This allows us to have the two options side-by-side. Feels like the above approach takes too many steps at once. Sorry I didn't get to finalizing the PR where we compile the stdlib with rewatch but I don't have the impression that it's hard. We just have to determine if we keep the cyclic deps, or refactor them out, we went for the last and that seemed to work. Just need to spend some time to make sure everything is properly compiling.

from rescript-compiler.

I think the stdlib mini would be pretty nice to have, as it isolates all the special cases. If I understand correctly, everything else can be built user-level on top of it without tricks/surprises. So it seems doable and independent from the details of the other steps.

from rescript-compiler.

Feels like the above approach takes too many steps at once.

Thanks for the feedback. My feeling was the opposite, that doing it in the compiler would mean taking too many steps at once. IMHO it is hard to refactor all this until it has the proper structure while still keeping the old build process working. (Unless we copy everything to a new dir in the compiler repo, but then we may as well put it into a separate repo temporarily to be able to iterate quickly, like we did for Core itself.)

I think the stdlib mini would be pretty nice to have, as it isolates all the special cases. If I understand correctly, everything else can be built user-level on top of it without tricks/surprises. So it seems doable and independent from the details of the other steps.

Definitely! Everything can be built from scratch in user level, starting with the stdlib mini. (Even with bsb, and even with the v11 compiler with -nostdlib). I'll put up a repo tomorrow with what I have now (basically step 1-4).

from rescript-compiler.

Ok, so here is my repo: https://github.com/cknitt/rescript-stdlib

It uses compiler v11.1.3-rc.1 with -nostdlib -nopervasives. This ensures that everything is indeed built from scratch.

You can clone it and run npx rewatch to build with rewatch, or npx rescript to build with bsb.

It will then build in one go:

• a mini stdlib (not quite mini enough yet, I had to add some part of Js, too)
• belt, depending only on the mini stdlib
• runtime (caml_*), depending only on the mini stdlib

This is based on #6772, but further modified to get it to build in this setup.

Next up would be adding Core.

from rescript-compiler.

Moved my repo to https://github.com/rescript-lang/experimental-rescript-stdlib-build

I have also added Core in the meantime and adapted it a bit to fit into the structure.

from rescript-compiler.

Some questions:

1. I want to be able to build runtime, belt, Js, and the OCaml stdlib without relying on Core being present (and am already doing so now for the first two). A consequence of this is that common type definitions cannot have Core as their source. I have collected these type definitions in https://github.com/rescript-lang/experimental-rescript-stdlib-build/blob/main/stdlib-mini/src/js_types.res for now. Maybe at least some of these should actually be builtin types?
2. What we need to be able to rely on though when compiling ReScript code is runtime (caml_*) to be present, see #6836. Therefore the question is, shouldn't the basic types and the "stdlib mini" actually be part of the runtime as caml_types and caml_pervasives or something like that?

What do you think @cristianoc @zth?

from rescript-compiler.