chore(monorepo): 🤖 split mono-repository into libs and packages (semantic distinction)#944
Conversation
|
|
Claude finished @punkbit's task in 42s —— View job PR Review✅ Looks great! This is a clean structural reorganization. The PR correctly:
No bugs, regressions, or missing path updates found. The changeset bot warning is expected — this is a pure infrastructure change with no version bump needed. Nice work on the clear separation of intent between "what we ship" ( |
|
Claude finished @punkbit's task in 1m 3s —— View job PR Review
✅ Looks great! Clean structural reorganization — no issues found. This PR does exactly what it says: moves Checked:
The changeset bot warning is expected — pure infrastructure move, no version bump needed. 🙌 |
7acd2aa to
84d4cfc
Compare
|
Claude finished @punkbit's task in 1m 7s —— View job PR Review
✅ Clean structural reorganization — looking good! Pure path migration: 💡 Suggestion (non-blocking, docs only)
Otherwise the PR is good to go! 🙌 |
|
Claude finished @punkbit's task in 1m 17s —— View job PR Review
✅ Clean structural reorganization — looking good! Pure path migration: 💡 Suggestions (non-blocking, docs only)
Otherwise the PR is in great shape! 🙌 |
ariser
left a comment
There was a problem hiding this comment.
It's hard to look through all of the changes in PRs like this, so I'm basing my approve on the general idea and green CI
Yes, it'd be much easier for me, too, to keep these in context. But based on previous file architecture changes, I'll be told the branch changes are too big. This is where the comment I made during a call came from, where I said the same thing you mentioned here, e.g. single purpose. At the end of the day, I'll need runtime to confirm everything's ok, e.g. CI, scripts, so there'll be revisions surely. Thanks for checking! |
f975b48 to
aca751f
Compare
cce0b21 to
494de80
Compare
|
Claude finished @punkbit's task in 59s —— View job PR Review
✅ Clean structural reorganization — no regressions found. All 9 workflow files consistently updated 💡 Suggestions (non-blocking, docs only — same as prior rounds) These were flagged in earlier reviews and are still present:
None of these block merge. 🙌 |
aca751f to
8074a6b
Compare
…e distinction between development and consumer apps
494de80 to
ebe69ac
Compare
|
Claude finished @punkbit's task in 46s —— View job PR Review
✅ Clean structural reorganization — no regressions found. Pure path migration: 💡 Suggestions (non-blocking, docs only — same as prior rounds, still present)
None of these block merge. 🙌 |
📚 Storybook Preview Deployed✅ Preview URL: https://click-mnl22mgep-clickhouse.vercel.app Built from commit: |
Why?
The monorepo had no clear structural distinction between the core Click UI (we ship) and the packages we build with. The PR makes "packages/" the ingredients and "libs/" the core component library we ship!
Alternatively, the project could become a Design System. But since the goal is Click UI, we're mainly ensuring that the main component library is the core of this whole setup, e.g. lib/click-ui or lib/core or packages/core, something that determines its goal!
How?
click-uiintolibs/as the core thing the monorepo deliversiconsinpackages/, it exists to support Click UI, but can also be consumed independently by other consumersPreview?
N/A