Skip to content

Conversation

@AliceR
Copy link
Member

@AliceR AliceR commented Sep 15, 2025

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

With this setup, it will be much easier to keep track of our refactor and migration work!

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.
@netlify
Copy link

netlify bot commented Sep 15, 2025

Deploy Preview for veda-ui ready!

Name Link
🔨 Latest commit d27dd82
🔍 Latest deploy log https://app.netlify.com/projects/veda-ui/deploys/6920804e19508c0008fd4a9c
😎 Deploy Preview https://deploy-preview-1871--veda-ui.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

@vgeorge
Copy link
Contributor

vgeorge commented Sep 22, 2025

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 /app is a instance app that uses them and will be deprecated in the future in favor of next-veda-ui.

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
Root package.json with workspaces (pnpm or yarn). Add /packages and /apps. Create /packages/components as the new clean library folder.

Step 2 – Start migrating components
Bring over the most critical pieces from /app/scripts/components. Keep compatibility by re-exporting.

Step 3 – Move Storybook
Relocate to /apps/storybook. Reconfigure it to import from /packages/components.

Step 4 – Isolate legacy SPA and shared code
Move /app to /apps/legacy-spa. Extract shared utilities into /packages/utils.

Why this path

  • Clear separation between reusable packages and runnable apps
  • Proper decoupling between the library and its consumers
  • A standard, scalable setup that matches what we’ll need as VEDA grows

This follows the spirit of your ADR but pushes us to a more conventional and future-proof end state.

@aboydnw
Copy link
Contributor

aboydnw commented Oct 28, 2025

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?

@vgeorge
Copy link
Contributor

vgeorge commented Nov 11, 2025

@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?

@AliceR
Copy link
Member Author

AliceR commented Nov 11, 2025

We could also merge it as "proposed", for posterity – what do you think?

@vgeorge
Copy link
Contributor

vgeorge commented Nov 11, 2025

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.

@vgeorge
Copy link
Contributor

vgeorge commented Nov 21, 2025

It would be nice to hear feedback from the rest of the team on this ADR.

cc @dzole0311 @ifsimicoded @snmln

@ifsimicoded
Copy link
Contributor

ifsimicoded commented Nov 21, 2025

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:

  • Clear component library boundaries
  • Unified documentation and development
  • Future-proof architecture for standalone library
    👏

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

  • Add existing tickets.

    I would like to suggest adding already ticketed issues to the list of more specific goals of the new stand-alone library. I didn't read all the tickets in detail, but maybe we could do a quick sweep to see what can be managed via this work. If this work can close several pre-existing issues, I think that would easily demonstrate even more concrete value as an initiative.

  • migrate component-by-component.

    starting with foundational components, we should be able to systematically manage pre-existing issues 🤞 depending on bug complexity. And we should be able to work concurrently. The SPA can be built out incrementally as well, as components become available.

Concerns:

  • Commitment to finish and concrete timeline

    If there isn't full commitment to finish this work on a well-defined timeline with broad communication to the bulk of the library's contributors, a gradual migration strategy, especially with a temporary dual build system with contributors still adding code to the legacy system, can lead to an even more fragmented state of the library, where maintenance becomes even more confusing with increased opportunity for esoteric bugs.

@vgeorge
Copy link
Contributor

vgeorge commented Nov 25, 2025

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants