We want to keep up the pace and announce our next ReScript Office Hour!
What are ReScript Office Hours?
This is a remote event where everyone in the community to talk about ReScript. This time will be casual, no concrete items to be discussed, we want to hear your feedback in general to prioritize things for the roadmap of 2021.
Hi all, thanks for the participation, it seems that the timezone is evenly distributed, so that I will take the same time as last office hour
Dec 23/ 7PM-8PM (GMT+8 Timezone)
The link fo joining the conference is updated in the main thread.
If you cannot make it, you can ask questions here, we will answer them during the meeting.
Excellent, thanks for sharing this here too @Hongbo! Dynamic imports are mentioned in the doc (I also started a thread about that a few days ago) - for those of us who won’t be able to attend the office hours, could you expand a bit on the plan around dynamic imports?
For this particular issue, we addressed the most pain point: the installation time. Now it’s just a couple of seconds to install bs-platform which is actually smaller than an average npm repo, in that case, add bs-platform to your consumer sounds not that bad.
So the real benefit of separating stdlib from compiler is just the package size, it is not a very big win in my opinion. There are some downsides when separating the compiler from stdlib though, user has to install 2 packages, we are unclear how to ensure package manager to lock them into a single version. We need more benefit to justify such change
I’m sorry but you seem to have misunderstood the request for a separate stdlib. Size is only a small part of it. I didn’t realise this until now, but your summary issue about it missed one of the original issues:
This issue very clearly states the reason I and others have requested this for years now. We want to publish compiled JS libraries from ReScript that depend on just the stdlib JS files. It is nice that bs-platform no longer compiles OCaml, but there’s still over a hundred megabytes of things that are not relevant to a library published in this way.
So yes size matters but there are plenty of other factors that matter for projects where the node_modules folder needs to be published; of the top of my head I can think of security as a big one, uploading unnecessary binaries is never a good idea, and bandwidth / hosting costs are another. In Javier’s specific example creating a vscode extension means the binaries must be uploaded to Microsoft, who might have a problem with it if the extension becomes popular while including a hundred megabytes of stuff that isn’t used.
I will admit the vast majority of ReScript users today don’t need this. They’re building ReScript applications or libraries designed to integrate into ReScript applications. However in terms of the wider JS community that is quite limiting, and I think being able to publish a library for JS users without depending on the full bs-platform is a good goal to have.
Sorry, I missed the event, too, and I also have a question: What is the status of the monorepo support now? My understanding is that with 8.4.2, bsb -make-world already (re)compiles everything it should, but still needs to be reinvoked manually because file watching is not there yet.
Is that correct? If so, when can we expect a version with monorepo support including file watching? (I didn’t see that in the roadmap at all.)
Hi, the roadmap is not an exhaustive to-do list.
With regard to your question, the thing is that “file watching” is completely decoupled with the build process so this can be done in the user land without any performance penalty. We will keep this on the radar
