search

JUSTIVE / ts-belt

🔧 Fast, modern, and practical utility library for FP in TypeScript.
https://mobily.github.io/ts-belt
MIT License
5 stars 0 forks source link

Discussion: Migration to Rescript Core #10

Open ksaldana1 opened 2 months ago

ksaldana1 commented 2 months ago

Thanks for taking the initiative to create a fork @JUSTIVE. I wanted to start the discussion you started here regarding the migration to rescript-core.

I wanted to start breaking down that work a bit to see what you think that would look like. I am still wrapping my brain a bit around the workflow in this repo, which is a bit of my inexperience in publishing ReScript into TypeScript. The relationship between genType and the TS declarations files isn't exactly clear to me—are the gen.tsx files used or were they just used to get the initial types?

Either way I understand that we need to change the underlying Belt usages to rescript-core, but I'm wondering if you had any stronger opinions on what you think that looks like. I am curious if the rescript-core team has any interest in a light TypeScript shim over their new core library. To me, it seems like a great way to incrementally sell people on the idea of ReScript and it's FP roots, but I understand if they don't want to take that on that extra work.

JUSTIVE commented 2 months ago

I'm also on the way to understanding the building steps of this library yet, it's a bit more than just rescript's gentype. These are the current version of understanding what I've got, in the simplest version:

  1. the rescript file's generated type goes to .gen.tsx.
  2. if you want to override some types, write it on to (module).ts files under src/(module).
  3. Some code shift works, then write it to (module)/index.ts
  4. bundle goes on

script/build.ts will give you a hint about the build process.

my original idea of the goal of migration towards rescript-core is, primarily, not to leave this library outdated. I'm more interested in fixing the glitches in the latest version(4.0.0-rc5) and some minor changes(mostly I left on the original repo's PR) now. I'm not sure the rescript-core team is interested in this, but basically, I think this project is a completely independent one.

JUSTIVE commented 2 months ago

there are some points to concern:

JUSTIVE commented 2 months ago

about the backward compatibility, maybe we can let both(Belt and core) exist, while migrating. Each modules must be in a flat hierarchy for tree-shasking, so here's a my inital idea is like, for Array module:

A(for Belt.Array, no prefixes for backward compatiblity) cA(for Core.Array, prefix c stands for core).

higher module like Core.A or C.A will hurt tree shaking.

ksaldana1 commented 2 months ago

about the backward compatibility, maybe we can let both(Belt and core) exist, while migrating. Each modules must be in a flat hierarchy for tree-shasking, so here's a my inital idea is like, for Array module:

A(for Belt.Array, no prefixes for backward compatiblity) cA(for Core.Array, prefix c stands for core).

higher module like Core.A or C.A will hurt tree shaking.

I like the idea of reaching parity incrementally by having separate modules for Belt vs core. That would make it a bit easier to continue to fix some of the outstanding bugs that currently exist. Can track how well the core-backed APIs match up with the existing test suite to determine when the migration is done.

I think the goal of 1:1 backwards compatibility depends a bit on your goals with this fork. Is the ReScript library backing the API an implementation detail, or is the goal to just be a straight copy of its underlying ReScript API? As a fan of ReScript I like the idea of being closely tied to the underlying API, since I like seeing this library as a stepping stone, but I understand the trade-offs here and think either approach works.

Curried functions are needed for the pipe API right? What would the alternative be to maintain this functionality?

JUSTIVE commented 2 months ago

I'm not sure about the goal of this library at this point. As I said above, my imminent goal is fixing the current version's API and the core migration. For the goal, I have two separate Ideas for it:

  1. The ts-belt is a powerful functional programming library backed by rescript.
  2. ts-belt is a typescript ported version of rescript stdlib.

the current version of ts-belt APIs is not paired with Belt's already. Some modules got more, some had less. should we deprecate unpaired functions that rescript doesn't have at this point?

We can leave this conversation open so that others come here and leave more ideas.