ReScript 12 just got released, and a key ingredient in this version was online contributions. However you spin it, none of this would have happened without our passionate contributors.
That said, I’m curious: are there any hurdles when getting started contributing to ReScript or the wider ecosystem?
For context: I’ve contributed quite a bit in the F# world, including the compiler, tooling, and even projects like Fable. At some point I felt like curly braces again and started playing with ReScript. One thing led to another, and I ended up contributing to various parts of the toolchain and joining the core team.
Now that I understand most of the toolchain, I might have some blind spots about how difficult it is to start contributing. I got onboard kind of by accident; how could we make that process more structured and easier for others?
So my main question: what can we do to improve the new contributor experience?
I’d love to hear if there was ever a point where you wanted to scratch your own itch but stopped because something got in the way.
Try and think broadly about this: the compiler, build system, tooling, bindings, website, create-rescript-app, tutorials, and beyond.
Once I wanted to add some types to the core library. Unfortunately it wasn’t enough to change the rescript files - I had to run some scripts to create the completions.
I didn’t know that. Well, the CI told me, but I was totally lost.
I had to use ocaml, or python or both to run these scripts. I had both installed, but it didn’t work.
So, how can we improve the DX?
Maybe a docker image or something to spin up the whole toolchain? Would probably lower the bar for new contributors.
The treesitter repo doesn’t have a real contribution guide.
I would like to support the new regex syntax, but I don’t know, where to start. Do I have to update the grammar or is it enough to add the query or injection or whatever? How can I test it before / after my changes?
Personally, and I don’t even know if it exists, I’d like a process document such as
Adding functionality to the standard lib
1.1. Write RFC, get feedback, something something
1.2 Edit the file in stdlib (e.g., Stdlib_Array.res).
1.3 Make sure to update the .resi-file if changes are made that affect the interface
1.4 Write at least two relevant test cases under wherever/tests/Stdlib_Array_test.res
1.5 Create a pull-request on this format: …
1.6 Wait for it to be approved
I have ideas, my main hurdle right now is that I don’t know how to submit the changes without it causing extra work for the team because I don’t know where to add the tests, how to find files etc
Would also like to see similiar (2., 3., etc.) for editing compiler internals etc
Also I would like a general “sitemap” over the source code so I know where to find what
This is a good point, the repo now has an up-to-date dev container that should allow you to easily spin it from vscode or even a github space on your browser!
Yes, this is very good point. I believe there are two problems here:
One is technical, you are expected to be able to build the entire compiler/build tool locally before you can add something to the standard library.
One part of that is a bad analysis test that will fail if anything changed in the standard library. Another bad part there is that installing all the OCaml stuff can be very rough.
The other problem is governance, there is no good process to add new things to the StdLib. It kinda happens and might benefit some formal decision making process.
Yes, another good point. I fear there this repository is largely the work of one individual, so we should indeed focus on making it easier for others to step in.
i don’t have anything particular i mind at the moment, but it pops up now and then, usually with regard to missing stdlib functionality. let’s consider the case of adding a function to Option for example. what would the process look like? how do i find the right files (i know this one but let’s step it through) to edit? when should i add tests? where should i add tests? how do i run the tests locally? should i only put doc comments in .resi? and so on