Hey guys, I have got everything working with vim-rescript and also the vs-code language server working with vim-coc but when ever I am in my main mono-repo project using yarn workspaces, the RescriptFormat command fails with an error message: rescript format returned an error.
Again, this works perfectly fine in a fresh simple flat app using create-react-app with no problems.
@ryyppy@dan003400 I was just looking into this problem.
The thing is that yarn workspaces puts the compiler and formatter in a very specific position, which is currently not taken care of by the heuristics.
I believe this resc_command output is what is not working correctly, as that is not located in the sub-package, its in the main root directory node_modules.
Creating a symlink to the bsc.exe in the sub-package allows the format on save to work, but then causes issues with duplicate dependencies and the package.json is also needed or compile errors happen.
The LSP and vanilla vim functionality are independent here. Formatting via :RescriptFormat runs our g:resc_command, which is calculated here.
The question is how the editor integration should behave, since it depends on when and where you open a file. If you are e.g. opening the vim editor in the root folder of the project, where does the vim-rescript plugin find the right binary?
I think yarn workspaces does a few funky things, such as dependency hoisting into the root project node_modules or something?
How would packages with multiple different bs-platform versions work? Kinda tricky questions.
Any hints on design ideas would be great, because I donāt have a lot of experience with typical lerna / yarn setups.
Edit: if there are any public ReScript / yarn workspace projects on github, would appreciate some link so I can have a look at it.
Iām working off this repo, provides a pretty good example.
The compiler exe seems to be located in the top folderās node_modules, the build artefacts in the subfolder
Yes, you are correct when using yarn workspaces, it hosts all the node_modules in the top level root directory.
It doesnt seem to matter where I open vim, but I think best practice would be to open vim from the root directory when working on projects using workspaces.
I am not 100% sure how this would work if using multiple versions of bs-platform across sub-packages in the workspace.
I guess the build artifacts always land next to the bsconfig.json. @Hongbo is currently working on better monorepo support, I wonder if this will stay the same?
Yeah we probably will need another vim function that allows calculating new g:res_bin_dir, g:resc_command, etc. ⦠that way we could use autocmd to automatically look for a new bin dir root whenever you edit a res file.
Is there a hack cmd to get the g:res_bin_dir working with the current setup in the meantime?
We have this working for now with symlinks but this causes a ton of duplicate dependencies since we needed to symlink the bs-platform/package.json file as well to get it working. But once those warnings pass we at least have auto formatting.
g:res_bin_dir is not really used for anything else after initialization. You need to set g:resc_command and g:resb_command accordingly, which can be done by
If you are using Plug, you could also just go into the vim-rescript directory and modify the autoload/rescript.vim by copying the rescript#Init function (e.g. rescript#ChangeBinPaths), and then you could use an autocommand to automatically run it on every file open:
" in your vimrc
augroup rescriptFixes
autocmd!
autocmd FileType rescript call rescript#ChangeBinPaths()
augroup END