Move component library to own repo

[tomjeatt]

We want the component library to be available to other applications. Task is:

1. Move component library to own repo
   • This includes shared assets (e.g. token icons) and form utilities (i.e. useForm hook, validation tools)
2. Configure build/release tasks as necessary
3. Update interbtc-ui to use component library

[danielsimao]

How are we going to deal with the theme?

[tomjeatt]

How are we going to deal with the theme?

TBD—we'll discuss it (and other related issues) before we start work on this.

[danielsimao]

ADR (Architectural Decision Records)

Summary

Issue

We want to move our component library outside of our interBTC dapp so it can be re-use across other products

• We want to use the same code base already used in the component library
• We need to bundle our component library and publish it, knowing that is not solely compose around components but also:
  • assets (svgs that are dependent on our Icon component)
  • theme (how are we going to separate our components from previous themes)
  • hooks

Decision

• parcel
• monorepo, turbo (fallback for monolithic if things get too complex)
• vite
• pnpm
• separate assets from component and hooks

Status

TBD

Details

Assumptions

We want to move our component library without making any changes to the codebase. We want to have access to any kind of code either in the same package our in each respective packages We want to decide on a quick approach without having to spend more time on documentation or configuration

Positions

Bundler

There are many approaches to how a component library should be bundled, but we aim for a simple a quick approach to it. For that, we have parcel as a great approach:

• Zero configuration: the only configuration required is the necessary params on package.json.
• Works well for our basic necessities for compiling react-typescript and css

On the hand, we could opt for:

• webpack: it more configurable but also complex
• rollup: a good alternative but more complex than parcel

Monorepo

This not a very important requirement but having a monorepo would be very fruitful for us at least for separating components from assets. Having them separated would be also that they would be published into different npm registries, which should be fairly easy. Some known tools for this are:

• turbo: on top of the game right now
• lerna: it was deprecated

NOTE: might require spending a bit configure turbo pipelines and publishing package flow (changeset)

Local development

Having a quick local development is ideal and for that there is a new tooling that is worth taking a look at:

• vite: faster and easier than webpack
• webpack: old school but widely used

Package Manager

There are some new tooling that is worth looking at.

• npm: we all know about
• yarn: we currently use it
• pnpm: faster and with a smarter way of managing the packages (re-uses packages)

[github-actions[bot]]

Running Lighthouse audit...

[tomjeatt]

We should also think about Storybook—I think we're likely to want to take that out of the app and include it with the component library.

[danielsimao]

We should also think about Storybook—I think we're likely to want to take that out of the app and include it with the component library.

Yes, I have a suggestion for that

[tomjeatt]

@danielsimao following up from this PR: https://github.com/interlay/interbtc-ui/pull/1553/files#diff-cf4cb5f6206e0ba35b3622f57a11bc28890005773a079d0ec1f4cd51b5a020e1R81

We have a duplicated formatting utility, which could cause problems when we split the code out (i.e. introduce bugs if we update one but not the other). I don't think there will be many instances of this, but we should give some thought to how to handle it.

(This isn't a critical/high requirement—probably something we add as a task to the new repo).

[tomjeatt]

Closing this—repo's been created. Will open a new task to migrate Interlay UI.