Avoiding reason-cli and just using bs-platform and reason-vscode together is the way to go in this ecosystem.
The problem with reason-cli is that it can get out of sync with the bs-platform version and fail in unclear ways.
There was quite a bit of pushback against reason at my shop due to the interop between these two packages and trying to do things like have autocompletion fail because of them.
It’d be nice if the upgrade of bucklescript to the OCaml 4.6 drops soon too.
Hi, I work on Reason full time and have been managing the reason-cli releases, and I'm happy to say that we're pretty close to not needing reason-cli anymore because the much better alternative is to _avoid_ global installs and instead model IDE support and as devDependencies of your project. We only have been releasing a global install (reason-cli) because:
1) Until recently we didn't have better alternatives for BuckleScript based projects (but then Reason Language Server came along)
2) We didn't have a good way to quickly install per-project dependencies for the Reason Native workflow. But then we built esy for native workflows which makes it very fast to install large dependencies across multiple projects by using a relocatable immutable package build cache.
Now, there's much less reason to use a global install and global installs will always have the problem of conflicting with project dependencies. I think you're picking up on that fact. Here's to the sandboxed project future!
This kind of stuff is often discussed in the Discord ReasonML channel so if you're ever curious to read the pulse on the direction of dev tools, feel free to join the discussion.
The problem with reason-cli is that it can get out of sync with the bs-platform version and fail in unclear ways.
There was quite a bit of pushback against reason at my shop due to the interop between these two packages and trying to do things like have autocompletion fail because of them.
It’d be nice if the upgrade of bucklescript to the OCaml 4.6 drops soon too.