start using futarchy-ts instead of lib

[decartesol]

By switching lib to futarchy-ts (a separate repo) we get the following:

• we can reuse the logic in other projects leading to less logic duplication (futarchy-indexer)
• more up-to-date client versions can be added to the frontend repo sooner (ex having Joe Build's AMM program export types directly to futarchy-ts
• by packaging futarchy-ts as a standalone library, we'll be forced to make the API more consumable by others, making it more likely that others can build on top of the metadao in the future.
• faster CI/CD since the futarchy-ts repo can just run tests for its own logic while the metadaofrontend pipeline no longer needs to run tests for futarchy-ts code

Thorns to be aware of:

• users should now run git submodule init && git submodule update after cloning the FE repo in order to get the futarchy-ts directory populated
• when updating futarchy-ts, there'll need to be 1 PR in the futarchy-ts repo then another in the FE repo to update the commit pointer

[R-K-H]

Love this, I'll have some more time to review this in the coming week. Is there any reason to not just have NPM install (and deploy to npmjs) and be pushing the needed stuff into the -ts repo instead of needing to deal with submodules?

[decartesol]

Is there any reason to not just have NPM install (and deploy to npmjs) and be pushing the needed stuff into the -ts repo instead of needing to deal with submodules

The main issue I see here is w/ local development. If I need to change the lib code and the frontend code as part of the same change, submodules has a clear local dev story for this, whereas if we're not using submodules we need to come up with some alternative standard (like perhaps cloning the -ts repo beside the FE repo, npm-linking to the -ts repo then before pushing, changing it back to the npm version). It's doable, but seems like submodules is simpler. If submodules is unpopular we can come up w/ something else like what I mentioned.

[R-K-H]

Nah, just looking for clarification. Both are what I would consider unstable, so I'm not worried about how best to move it forward. I use and have used submodules for many things, so it is perfectly acceptable and sufficient IMO.

Edit: The only other thing I can think of is we can reference the github and commit / tag directly in the package.json as well, which can work locally.

The second thought I had was that building from/for github pages if it works? The ability to migrate to a Vercel or other provider instance is probably called for in the near term, so likely won't matter for long.

[decartesol]

building from/for github pages if it works?

It should work after the

with:
  submodules: 'true'

change I added to the checkout github workflows.

can reference the github and commit / tag directly in the package.json as well

does that work locally? I thought it would no longer use the local git submodule in that case. I'll check