seperate components and convert to monorepo

[nicholaswbowen]

Monorepo setup.

This makes no functional or pattern changes, it just separates the code into 2 sub-modules. @srcl/ui is a presentational react component library, optimized for modern code splitting. www-sacred is an "as-untouched-as-possible" implementation of the demo site.

www-sacred

still runs nextjs, and consumes reusable components from @srcl/ui

Here's what moved:
/components > @srcl/ui
/hooks > @srcl/ui/hooks
/common/modules > @srcl/ui/modules
/common/utilities > @srcl/ui/utilites
/common/position was consolidated into @srcl/ui/utilites
moved ModalProvider to @srcl/ui/context

What stayed:
constants, queries.ts, server.ts stayed in /common
/app, /examples, /page, /pages, /public, /svg

• some small changes to the tsconfig to make it play nice with the monorepo.
• named exports instead of default ones.

@srcl/ui Overview

A big bucket of beautiful components. overall pretty simple. The folder structure is setup in this way to take advantage of tsdown's auto-generated exports in a clean way. This matches pretty well with the previous style of all the files in the folder side by side, now it just have nested folders with index.ts files. This is how we get the clean @srcl/ui/Accordion, @srcl/ui/hooks, etc. without manually updating the package.json.

No barrel files = no user footguns

I have found that people very often don't understand why their bundle's dependencies are so large. And it can often be due to npm pulling in every last component attached to a barrel file. The bit of extra boilerplate this causes is minor to me.

// no barrels
import { Accordion } from "@srcl/ui/Accordion" 
import { Button } from "@srcl/ui/Button" 
import { Card } from "@srcl/ui/Card" 

// with main barrel
import {Accordion, Button, Card } from "@srcl/ui"
// I agree this looks nicer, but it's just not worth the downsides, a few extra lines in your components is the worth the impact it has on end users and frustrated developers who don't know better.

tsdown

Pros:

1. Low config
2. Generates your package.json export statements, works great with IDE autocomplete without needing big barrel files that mess with tree-shaking.
3. Specifically for bundling libraries.

Cons:

1. Lots of tiny index.ts files everywhere.
2. The format of consumer imports and file structure are coupled together.
3. a minor annoyance to me with react 19 is that you need "use client" at the top of the index.ts of the components, not the file itself. This is because tsdown is generating artifacts from those entries and puts the declaration in the wrong spot.

Alternative to monorepo

This would definitely make this PR less colossal.

Just make 2 repos, and do local development using npm link. This is mostly fine. Except that react this has this frustrating issue with hooks and link that requires you to link the consuming library to the site's node_modules/react, adding some complexity. Could be worth considering not exporting hooks at all if seperate repos are preferred.