skeletonlabs / skeleton

A complete design system and component solution, built on Tailwind.
https://skeleton.dev
MIT License
4.9k stars 307 forks source link

NEXT: investigate Vike for use in our sandbox apps #2817

Open endigo9740 opened 1 month ago

endigo9740 commented 1 month ago

Currently the Skeleton sandbox test apps for each component package are setup as follows:

In order to move to a more uniform structure for both these and other frameworks in the future we should investigate Vike:

This is a meta-framework built on top of Vite that provides a simple file-based route that should work consistently across all framework. This appears to cover all requirements we need for these dev-focused apps.

endigo9740 commented 1 month ago

@Hugos68 pinging you as you recommended this and might could use an assist in testing @AdrianGonz97 we might need your help updating the NPM deployment process for either package if we go with this.

Note this is low priority. Just something to investigate when we have the bandwidth.

Hugos68 commented 1 month ago

I've done some testing and the results are so far very pleasant. Vike is extremely unopinonated, it just gives us a router and the rest of the project is for us left to fill/utilize.

I've created an example repo using React here: https://github.com/Hugos68/skeleton-vike

Vike supports the following frameworks by default:

On top of that there are community adapters for more niece frameworks but I think this should cover our needs.

In the README of the project is the file structure explained but I'll send it here again for showcase:

├── package.json
├── pnpm-lock.yaml
├── README.md
├── src
|  ├── components
|  |  └── Counter.tsx
|  └── pages
|     ├── +config.ts
|     └── index
|        └── +Page.tsx
├── tsconfig.json
└── vite.config.ts
endigo9740 commented 1 month ago

Very cool. Again, not a huge priority since what we have is working. But I think we should evaluate switching before launch. Definitely before we introduce Vue.

@bartduisters just FYI!

Hugos68 commented 1 month ago

Any reason it's low prio? I wouldn't mind working on this. Makes developing a little bit better and makes it easier to contribute as all the projects will be identical.

endigo9740 commented 1 month ago

We could technically go all the way to launch with our current configuration. I'd rather focus on tasks blocking launch first. That said, if this could have any potential affect to the release process then we should do that while the project is still in a "work in progress" state.

Hugos68 commented 4 weeks ago

Understandable, I'll park this mentally then for now