yarn-plugin-rescript is a ReScript project tooling made with Yarn Plugin. I just migrated it to work with Yarn 3.
It analyses ReScript dependencies using the Yarn API. And automatically unplugs and links it so the compiler can find the dependency.
This is similar to what pnpm does, but only does what is needed, so the rest of the dependencies can still benefit from Plug’n’Play
It also provides convenience features like yarn res init and yarn res add. You can automate initializing and managing bsconfig.json
Yarn’s plugin system is awesome, there are other possibilities that haven’t been discovered yet.
I don’t understand what should does standalone link command for
It’s for interop with PnP, and so relies heavily on the PnP abstraction layer provided by Yarn. I’m not sure if it’s worth more than just dealing with filesystems in other package managers without Pn
Right, I thought link would (also) iterate over the installed ReScript packages and add them to bsconfig.json if missing, but it is actually just making yarn link compatible with ReScript.
What I am really looking for is a way to automatically add all missing dependencies to bsconfig.json, or a way for libraries to add their deps to bsconfig.json automatically after installation. Not (necessarily) tied to any package manager (but obviously tied to the node_modules-workflow).
Feels like a long term preference would be to not have dependencies in bsconfig.json. Once a linking mechanism exists, the array in bsconfig is just a cache. Could make -with-deps parse package.json, and then cache automatically until the next with-deps call.
Hi All, I notice that the yarn rescript plugin does not support rescript.json, consequently it does not currently work with rescript 11 if the json file is migrated.
While the plugin can be updated, it was never perfect, so this opens the question: what do you use with rescript and yarn pnp? What’s the best practice?
If the answer is “don’t use pnp” or “use another package manager” I can also understand that, but I’d like to know what others find as the best solution.
Since the plugin has never been updated, compatibility with Yarn as well as ReScript is not currently guaranteed.
What I can tell right now is that ReScript is very dependent on Node’s module resolution and there is no possibility of changing that anytime soon.
One conclusion I came to while dealing with PnP and Deno binding is that a ReScript-specific package manager is likely to solve it. I’ll probably be experimenting with it personally sometime in the middle of next year.
For now I mainly use nodeLinker: node-modules for my projects.
Fww I’m using pnp in a couple of projects with the plugin, I might update the plugin to use rescript.json when I have some free time and continue using it until we have a real pnp story.
Could you enlighten me, what makes our case different from Typescript? Since it also needs to access the definitions, we should be in the same boat. Although I like the idea of a Rescript-specific package manager, being able to use “any” package manager would also be desired imo.
Could you enlighten me, what makes our case different from Typescript?
Same as Flow, Bsb (the build system) is code written in OCaml and assumes the presence of node_modules in the filesystem.
TypeScript is, to some extent, an extensible moduleResolution, and because it is JavaScript, hooking is not difficult.
The ReScript-specific pm idea is,
Centralizing compiler binaries and dependency registry. Dependency builds are done only once, globally and when needed. It should create the necessary resolutions (node_modules, import maps, etc) from the project lockfile.
This sounds interesting. Out of curiosity, how will this manage rescript dependencies (EDIT: dependency to rescript itself) from package.json? I mean, since rescript won’t be a “pure” js dependency any more, how will we manage dependency from a package to a given compiler version?
Also, would this also support the monorepo story? Currently working with rescript monorepos is in a sad state, and this should also work out of the box. A new package manager looks like a good opportunity to solve this problem, too.