-
Notifications
You must be signed in to change notification settings - Fork 13
docs: Add ADR 004 - Component Library Restructure #1871
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Proposes renaming /storybook to /core and establishing it as the primary location for library components with gradual migration from the current scattered structure. ## Context - Current library components are scattered throughout /app directory - Need clear separation between library and application-specific code - Opportunity to modernize build system based on successful Vite adoption ## Proposed Solution - Rename /storybook → /core to reflect library purpose - Gradual migration strategy with backward compatibility - Dual build system during transition (legacy Parcel + new Vite) - Re-export strategy to avoid immediate component copying - Future state: standalone /core package ## Benefits - Modern development environment with Vite - Clear component library boundaries - Unified documentation and development - Future-proof architecture for standalone library - Low-risk incremental migration path Addresses the natural evolution from the successful split architecture that enabled Storybook development, building on proven Vite benefits.
✅ Deploy Preview for veda-ui ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Hi @AliceR, thanks for putting this ADR together, this is much needed. I agree with the problem statement and the decision to give our component library a proper home. Thinking about the long term, I’d like to propose a small shift. My view is that the component library should be a standalone package, and apps like Storybook or the legacy SPA should be separated from it. Storybook is just a dev viewer for components (and potentially a docs website in the future), and the SPA in That’s why I think it makes sense to set up a monorepo with /packages and /apps. It gives us the target structure right away, and the migration then becomes about moving things into the right place. Proposed steps Step 1 – Create structure Step 2 – Start migrating components Step 3 – Move Storybook Step 4 – Isolate legacy SPA and shared code Why this path
This follows the spirit of your ADR but pushes us to a more conventional and future-proof end state. |
|
How does this approach integrate with the plugin framework repo that we recently started, and with this idea that the plugin marketplace will have plugins made from components outside of veda-ui? |
|
@AliceR given that we are entering maintenance mode on veda-ui and focusing on bug fixes and maintenance tasks, do you think we should close this? |
|
We could also merge it as "proposed", for posterity – what do you think? |
|
I think we can merge, but could we update the ADR to reference this PR and #1898? That one introduced the monorepo structure we discussed in check-ins, and linking both would help preserve the context. |
|
It would be nice to hear feedback from the rest of the team on this ADR. |
|
If the goal is simply to move files, and introduce a new build (while maintaining the old), I'm not sure it's worth the time. If this is just phase 1 of a committed larger refactor by more than a couple individuals, that makes sense! Very keen on these broad goals:
Assuming this is just phase 1, here's some thoughts from my end (but please note I'm not familiar with the depths of this repo, so my approach could be off!!!) Suggestions
Concerns:
|
|
@ifsimicoded thanks for the feedback. I agree we should define concrete actions to get this across the finish line, especially since the PR has been open for more than 60 days. My proposed scope is:
Out of scope
|
Proposes renaming
/storybookto/coreand establishing it as the primary location for library components with gradual migration from the current scattered structure.Context
Proposed Solution
/corepackageBenefits
With this setup, it will be much easier to keep track of our refactor and migration work!