Fundraiser for better Editor Support in Windows (Without WSL)

[superherointj]

Fundraiser for Better Editor Support in Windows (Without WSL)

Why

Reason is still not at it's optimal support level in Windows because of shaky editor support.
Reason's VSCode extension requires Merlin and isn't working when running Merlin in windows runtime environment. Current best workaround requires running Merlin in WSL. WSL works but is unstable (known issues WSL#2613, WSL#2746).

Current Target

Improve editor support

Run Merlin (be it 2.5.x or 3.x) in Windows runtime environment working with VSCode Reason extension with all features (code lens, code completion, errors, hints, etc) working properly without requiring WSL. The focus is in improving developer experience. Not in getting Merlin ported to Windows native. (That would be great but not required.)

Future possible goal

• Improve Windows native toolchain.
  It is a large undertaking. Not current goal. Current priority is editor support. When done we can upgrade target (or start a new fundraising issue) until Windows support is rock solid. For now, baby steps.

On contributing

• As expected, any developer can participate. First to get it done can claim their bounty. :)
• Fundraiser organization process is open and ongoing.
  • Which platform should we use for fundraising? Suggestions?
  • For now, this is the main fundraiser page. Just post a message here stating your contribution.
  • The collection will probably happen on a platform that handles this properly. We are listing interested people, and once platform is decided, will be notified.

I encourage everyone that can or would like to help or support this cause, to join in and support the cause.
Be it by volunteering some effort or by pledging a few coins. Anything that can help is welcomed.

Current Pledges

1. superherointj 50 USD
2. romainquellec 25 EUR
3. chenglou 50 USD
4. frankwallis 50 USD
5. isaksky 50 USD
6. johann-sonntagbauer 50 EUR
7. leolimasa 50 USD
8. bryphe 50 USD
9. jordwalke 50 USD
10. saitonakamura 50 USD

I will add your GitHub's username here if you pledge bellow.

[superherointj]

I'm in. 50 USD

[rgripper]

Is there a fundraiser page somewhere?

[superherointj]

The fundraiser page is this issue. Feel free to join in and contribute to the discussion with your suggestions, thoughts on topic and show your support. :)

[rgripper]

How do you collect donations then? :-]

[superherointj]

Just say in and how much and later we collect. :)
@rgripper Do you have suggestions? What would you like to see different here? Do you like the target? Other thoughts?

[superherointj]

Actually the how much shouldn't be required. Only that you want to contribute.

[romainquellec]

Hey ! I'm on windows and sad about doing all this work !
I'm in for 25E. (euros)

[jubos]

Great idea!

It might be worth breaking the target into a few bite size subtargets given that getting Merlin + OCaml toolchain going on Windows natively has been a long running work in progress on the OCaml side. This is promising (https://fdopen.github.io/opam-repository-mingw/installation/) yet still requires Cygwin, so not sure if that is really any better than WSL. I have found the WSL integration gives me the majority of functionality in VSCode (Codelens + Completion + Refmt) with GoToDefinition being the only weak point due to path mismatches.

Here are a few related issues on the opam/OCaml front that might need to progress to really get Reason working well on Windows:
ocaml/opam#2191
ocaml/ocamlbuild#64

[jordwalke]

@jubos The mingw installation may be superior to WSL because it is possible for it to be silently installed and sandboxed without the user knowing. WSL is a great tool in my opinion, but it does require some intervention on behalf of the end user (to make sure they have the right OS etc).

If anyone is opposed to mingw purely on the grounds that it's an extra tool, you might ask how VSCode manages to get real git integration on windows. They use similar Unix abstraction layers (msys2 IIRC) - but you'd never know it because it's all hidden from the user, which is what really matters.

[romainquellec]

mingw seems to be a good solution. I looked at the issues, but it's a bit complicated to me.
Any timeline / deadline on it ? Do it solve everything for windows users using reasonml ?

[jordwalke]

@romainquellec This current issue is tracking improved support for a more specific use case of ReasonML: developing with Reason+BuckleScript on Windows. General windows support beyond the BuckleScript use case for ReasonML is another issue and will require more work/planning though we're thinking about it as well.

[chenglou]

I believe @superherointj is aiming for merlin on Windows native. This isn't BS-only. I'm in for 50 bucks

[jordwalke]

The header says "Fundraising for Better Tooling in Windows for Bucklescript/Javascript workflow". @superherointj Would you mind clarifying what you are raising funds for, if this is not correct? Would funds be delivered for only covering the BuckleScript use case, or would it also require that support for ocamlfind and native packages on windows also work to some extent? Merlin supports ocamlfind resolutions as well, and if we're talking general purpose Reason development on windows, we'd need to also solve ocamlfind (non BuckleScript libraries install via ocamlfind). I just want to avoid incorrectly setting expectations with the messaging of "We solved Reason for Windows" but when people try to consume opam libraries, nothing actually works.

[superherointj]

The initial goal is to improve editor support only. Run Merlin in Windows runtime environment working with extension without requiring WSL. It will improve development experience for all platforms/workflow.

This stage does not require improving other tools or having full Windows native support. (Which would be a much larger undertaking.)

The focus is in improving developer experience. Not in getting Merlin ported to Windows native. That could happen but isn't required.

[strega-nil]

I'm still a student, so I'm not in for any money, however I'd love to help out with the actual porting :)

[frankwallis]

Would be really happy to see this happen, count me in for 50 USD please

[isaksky]

I'm in for $50 USD.

[johann-sonntagbauer]

count me in as well 50€

[romainquellec]

Hey ! Any news on this ?

[superherointj]

Hi @romainquellec,
What do you want to know?
We should pick a platform to receive funds but this decision wasn't made yet. Is that your concern? Do you suggest a platform?
Things happen only when individuals take action.
Currently not a single core developer uses Windows. And interest in advancing Windows support comes mostly from Windows users.
Hopefully as Reason becomes more popular there will be more interest in advancing Windows. The main value of this thread is in keeping topic alive and keeping track of people willing to support this cause. It might take a while, this is probably a long term thing. Eventually, hopefully, we'll gather enough support to motivate a developer to get this going.
But I don't expect it to happen too soon. What are your expectations?
I am interested in advancing Windows, but beyond us here I don't know many people willing to advance Windows support. Most people say having Windows support 'would be nice' but aren't willing to do much to get this going. I often think about how we could be advancing Windows, but I haven't found a good way out of this yet.

[Schmavery]

Hey @superherointj
@bsansouci and I have been working fairly actively on trying to improve the story on windows lately (because we think it "would be nice" if windows devs could use reason too!). We just finished making bsb-native run on native (cmd.exe) windows (anyone feel free to message us or open issues if you have any trouble/suggestions) and I've been more recently starting to look into getting better editor support using a combination of changes to ocaml-language-server and by working to get windows binary of merlin shipping along with bsb-native.

Not sure how this will go as we haven't started trying to build merlin on windows yet but fingers are crossed. If anyone wants to help out, getting a start on the ocaml-language-server changes (https://github.com/freebroccolo/ocaml-language-server/issues/84) might not be a bad place to start (and even without windows, would improve bs-platform/editor consistency in general!).

I get that this might not the under the exact scope of this issue, but I thought it was related enough to be worth mentioning.

[superherointj]

Hi @Schmavery .
Thanks for working in improving windows story. And sorry for not taking your work into account in my previous message. It is certainly great that there is work going into Windows.

[patoncrispy]

I don't know what's involved, but I'd love to help out in any way I can. Only done a small bit of OS in the past but would love to get involved in the Reason ecosystem. New to Reason, too, but very happy to learn and help.

[leolimasa]

In for $50.

Loving ReasonML, but setting it up on windows is laborious. I also think this is crucial for it to gain traction on the larger dev community.

[bryphe]

I'm a bit late to the party here but excited to see the enthusiasm here! You can put me down for $50 too. 👍 My primary development machine is Windows, so this is my major hurdle at the moment. Coming from my "Redmond bubble" I know there are lots of other developers in the same boat here - so IMO this is critical to achieving mainstream adoption.

The future goal of having the binaries work natively on Windows definitely seems like the right long-term approach. Sounds like it will need significant investment, though!

For the nearer tearm goal of editor support - I like the idea of the cygwin and mingw stack that @jordwalke . I haven't used either tool recently, but if they do allow running merlin on Windows and getting editor support, the nice thing is that the 'setup' experience on Windows could be streamlined.

For example, there could be a reason-cli@windows NPM package that has a Powershell script run as a postinstall step, that would bring in a local cygwin (and then use it to bring in mingw) - all happening transparently on the reason-cli install. It could even be really nice and try and update your VSCode configuration for you, if it seems you have one...

It would be great to have the initial reason-cli steps be in parity across all platforms (with Windows doing some extra lifting to bring in dependencies): npm install reason-cli@{version}-{platform}. Eventually, once the longer-term goal of full Windows support is realized, perhaps cygwin / mingw wouldn't be needed in a future iteration...

IMO, one concrete way to start pressing forward on this would be to create a reason-windows-setup GitHub repo that can help test the reason setup on Windows, using AppVeyor builds.

• Install bs-platform
• Install ocaml-language-server
• Write test cases that validate aspects of the LSP against a simple bsb init project (go to definition, completions, etc). It's expected that these would fail at this point, because we haven't done any work yet to enable it. Having test cases that concretely specify the goals would be a big step forward in making this actionable!
• Write a powershell setup script that brings in cygwin and installs mingw + the required dependencies.
• Update the initialization arguments to ocaml-language-server to account for the new paths - hopefully we can start to see some of our tests turn 'green' at this point.

At this point, we'd have a blessed manual path with cygwin/mingw, and we know we can install the dependencies through Powershell.

EDIT: @jordwalke mentioned that a major challenge is the use of OPAM packages. A solid next step here would be to add a test case for installing an OPAM package, and then validate that the ocaml-language-server gives proper results for that package. Seems like this would be the real crux of the problem - getting those tests green.

The next step would be to integrate this powershell script as a postinstall script for an appropriate NPM package. Then, we'd have infra to validate build-over-build that the tooling works (or test on various Windows platforms + x86/x64).

Not sure if that's helpful or not; just some ideas! Can't wait to use Reason on Windows 👍

[jordwalke]

@bryphe I think that this particular Github issue is for a short term solution that only needs to work with bsb, doesn't need to work with native/opam packages, and more revolves around editing with merlin than building executables.

I can't recall if a mingw build of merlin itself is possible in its current form. I think there was some major compatibility breakage in the recent versions and someone is trying to fix that deeper in merlin. (Anyone recall?)

Separately, I'm also giving considerable support to more comprehensive windows support for a broader set of requirements (building of native packages, multiple versions of the compiler, maybe cross compilation). Many of the requirements revolve around the ability to build/run/link windows executables, as opposed to just developing on Windows. It's a bit beyond the scope of the proposal discussed in this Issue and it's operating on a different timeline, but anyone let me know (on Discord) if you are interested in another bigger challenge that will also help us move forward for proper long term Window support. While that is underway, count me in for fifty bucks for the proposal being discussed in this Issue!

[jaredly]

Oooh I'd forgotten this issue was around 😃 do I win the prize? I've got a language-server that works on windows https://github.com/jaredly/reason-language-server/releases/tag/1.0.0-beta.2
(there are a variety of unfinished things about it, but it's reasonably usable at this point)

[rgripper]

Ok, now we need ppl to verify that it's a yay-time :-)

[bsansouci]

To answer @bryphe, I think merlin should be compile-able on windows as it was before 3.0 and could work if we went and checked all paths to make sure they use appropriate separators. I'd be willing to bundle merlin with bsb-native, so that apart from the editor and editor plugin, the user only needs bsb-native.

[bryphe]

With the latest Windows work done on esy - merlin@3.1.0 is buildable on Windows via esy. (The limitation at the moment is that the esy lockfile needs to be generated outside of Windows, but I have a minimal merlin project w/ the lockfile here: https://github.com/bryphe/esy-minimal-merlin-project)

[jordwalke]

To properly manage expectations: I’ve heard that getting merlin to run correctly on Windows may still require some work to fix the path issues - it may require substantial dedication to find those issues and submit patches upstream. But what a massive accomplishment to even get it building nonetheless!

[yunti]

@jaredly great work on your reason language server. I know it's early days but how does the feature set compare vs the merlin one and would it take a huge amount of work to close the gap? (ie which option makes sense to get behind for the mid - long term?)

[saitonakamura]

I'm also desiring to add my 50 cents $ to the noble cause.