I’d like the user be able to run npm install my-rescript-component and use the component with import MyComponent from 'my-rescript-component.
I was under the impression that the generated js output would not be dependant on bs-platform. A bit surprising to hear about that hard dependency at runtime. Thought bs-platform was only for compile/build time.
It’s possible to write ReScript code that doesn’t require any of the bs-platform JS stdlib, although that would be very difficult for any non-trivial project. bs-platform ships a lot of JS functions that are automatically included for basic operations.
Another option is to use a bundler. I believe this is what Wonka does, for example.
I depend on rationale (https://github.com/jonlaing/rationale). The dependency doesn’t include any built js files when installing it with yarn, so you must run rescript build -with-deps, which puts the built js files inside the node_modules/rationale directory so that the js can be used.
Clearly this is a problem, as just putting rationale inside package.json would pull the npm package without any of the js in it.
Is this an issue with rationale? Should I be requesting that rationale includes built js files inside their npm distributions? Or should I run parcel over my build to therefore include the dependencies in one build file? Or is there something I’m missing?
In my opinion, this is one of the things that would allow for ReScript to have a wider adoption.
However, when creating a package to be consumed in a JS or TypeScript setting it is largely inconvenient that consumers — for any non-trivial libraries — need to install and configure the ReScript-toolchain (due to transitive dependencies not having JS artifacts published with the library).
We have a few services using ReScript (with React and GenType) at Wolt which are consumed in a TypeScript + React-application, and for us this has without a doubt been the one thing that has hindered ReScript from wider adoption.
The good news is obviously that ReScript has all the tools to make this possible and I imagine one solution would be to make it the convention and default to both publish the JS-artifacts (to solve the issue of transitive dependencies), and also follow the convention of specifying a package entry point and potential type definitions in the package manifest (for JS/TS consumption).
I do however think that the team needs to make it even more trivial to do so, and also to provide clear guidelines for the community on how to publish libraries.
ReScript is such a great language and I’d like to use it for any library I write regardless if it’s consumed in JS/TS or ReScript.
A couple of links to previous posts on this subject:
Perhaps I was unclear, but yes, this was the point. In theory, this is true. In practice, however — because most ReScript-library authors do not publish their JS-artifacts — it’ll require JS-consumers to install and configure the ReScript-toolchain.
For clarity, here’s a minimal example.
My Index.bs.js uses a function from some third-party library that hasn’t published its JS artefacts. When my library is consumed this will throw an error for module not found.
// Generated by ReScript, PLEASE EDIT WITH CARE
var Foo$SomeRescriptLibrary = require("some-rescript-library/lib/js/src/Foo.bs.js");
var foo = Foo$SomeRescriptLibrary.doFoo;
exports.foo = foo;
(I’d imagine that this would also apply if our bsconfig.json have different values for e.g. in-source or suffix.)
I think it might also be worth discussing if there may be some benefits of having e.g. an option not to compile from source (with some sort of compatibility check). I think it’d be especially useful when targeting consumers other than ReScript.