Hi, I was wondering if its possible to build a library that can be used in a pure js project and if so what steps are needed?
What I would want is to build stuff in rescript and then use it in my pure js project without rescript as a dependency. An example is building api services, so skipping stuff like zod.
I have some 3rd party dependencies inside in bs-deps and when I generate js files the generated file imports from File.gen for example.
Do I need something specific to get it to work?
Thanks in advance.
Hey! I don’t think ReScript has a seamless story for building JS libraries.
Additional bundler features can make it possible, but the truth is that finding a good build tool for your library is still a challenge in the entire JS ecosystem.
Some related conv:
And I had a plan for this personally
opened 02:49PM - 21 Nov 23 UTC
TL; DR: I will build a new esbuild-powered build tool, called **"espub"**
###… Brief history of nanobundle
nanobundle, as the name suggests, is a bundler. It aimed to provide effortless library building by adding some tweaks to esbuild's bundle mode. It's just like what [microbundle](https://github.com/developit/microbundle) does based on Rollup, that first inspired.
In v1, I focused on leveraging the full power of [conditional exports](https://nodejs.org/api/packages.html#conditional-exports) in Node.js. And since TypeScript didn't support multiple entries at the time, this was a reasonable compromise. As a result, it was sufficient to support “small libraries” use cases and is compatible with the TypeScript ecosystem without noise.
### Current status of nanobundle
I still use nanobundle actively in my daily work.
But at the same time, I see numerous cases where nanobundle is not a good fit because it is essentially a "bundler".
The bundler, by definition, removes the module semantics from the output after it has been performed. So I can't build things that depend on module semantics (I can approach it "cleverly", but it's overly complex or unpredictable)
While I was recognizing its limitations, I stopped exploring further features. And waiting for the ecosystem to move.
Time passed and things changed.
TypeScript projects can now adapt Node.js's conditional exports with the new [`moduleResolution` mode `Node16`, `NodeNext` and `Bundler`](https://www.typescriptlang.org/tsconfig#moduleResolution)
[Import attributes spec is standardized](https://github.com/tc39/proposal-import-attributes), and [esbuild has added support](https://github.com/evanw/esbuild/releases/tag/v0.19.7) recently. So users can specify more options at the module level. no need to customize loaders within the config.
[XState v5 is released](https://stately.ai/blog/2023-12-01-xstate-v5). It supports a better concurrency model than before with first-class actor support.
### So what's the plan?
I still have trouble finding build tools that work for me in many situations.
Type checking is performed independently. tsc/babel is too slow to transpile. Most tools still don't handle conditional exports correctly. And more importantly, I moved most of my projects to ESM-first. I don't want to "bundle" my lib codes anymore.
It seems like there is still a chance to build a perfect esbuild wrapper. So I will do that.
It will be rebranded under the name "espub" because it is no longer a "bundle"-first tool. It will still be able to bundle stuff, maybe I can keep the "nanobundle" as its alias.
### ETA?
I'm definitely exploring in this Dec, but I can't promise anything.
I'm personally having productivity issues, and I also have other projects I'm involved with. Maybe you can make it faster than me.
I've actually seen a few close ones like [tshy](https://github.com/isaacs/tshy), [pkgroll](https://github.com/privatenumber/pkgroll) and [bunchee](https://github.com/huozhi/bunchee). Unfortunately, none of them isn't for me. I don't expect someone to build it in a few months, so I'll do it soon eventually.
Just watch.
(Actually, I've already tried it a few times, and I rarely reuse existing code. It will be a completely rewritten codebase)
But none of that is about ReScript. So I opened an issue to track all the improvements needed to solve this issue in purely ReScript, and called it “Library Mode”
opened 09:50AM - 26 Apr 23 UTC
This is an umbrella issue to track and discusses the remaining issues to be reso… lved to achieve "Library Mode"
The "Library Mode" means that the ReScript compiler can be adopted as a first-class tool for building libraries in today's JavaScript ecosystem.
Opened RFCs
------------
- [ ] https://github.com/rescript-lang/rescript-compiler/issues/6196
- [ ] https://github.com/rescript-lang/rescript-compiler/issues/6209
- [ ] https://github.com/rescript-lang/rescript-compiler/issues/6530
- [ ] https://github.com/rescript-lang/rescript-compiler/issues/6946
Related changes
-----------
- [x] https://github.com/rescript-lang/rescript-compiler/pull/6709
- [x] https://github.com/rescript-lang/rescript-compiler/pull/6777
Open discussions
-----------
Tell us your story if you've ever provided a JavaScript library based on ReScript (not binding)
Library mode includes everything about it like, improving basic interoperability with Js/Ts projects, generating .d.ts
on the fly, publishing dual packages, etc.
It’s also the major milestone for v12.
Take a look and let me know if it’s close to what you want.
2 Likes
Before the library mode, my current recommendation is to use tshy as an additional build tool for genType’s .ts
outputs.
1 Like