Skip to content
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

Expose Vuestic build files as framework for building UI libs #3305

Open
m0ksem opened this issue Apr 6, 2023 · 0 comments · May be fixed by #3609
Open

Expose Vuestic build files as framework for building UI libs #3305

m0ksem opened this issue Apr 6, 2023 · 0 comments · May be fixed by #3609
Assignees
Labels
epic Feature that is too big to fit in one issue

Comments

@m0ksem
Copy link
Contributor

m0ksem commented Apr 6, 2023

I have a feeling that it is a common thing to make own UI lib in project. Maybe own UI lib over existing UI lib.

Why do we need this

A tool that improves DX when building own Vue UI lib. Currently, there are too many ways how UI lib can be built. I would like this process to be easier so you can create own UI lib in seconds.

What to do

We can expose our effort that made Vuestic bulletproof vs SSR, bundlers, etc. as a tool for building UI libs.

List of features we can provide:

  • Appended CSS, so ESM build has CSS tree-shaking;
  • Fixes for SSR;
  • A tool that makes Vue lib with zero config;
  • Stick to our file structure. We can take Nuxt DX as inspiration;
  • Built-in sandbox, similar we have to test lib in Nuxt, Vite, Webpack;
  • Built-in bundler tests;
  • Built-in histoire for components;

What to expect from tool for building UI libs:

  • Generates cjs, es, esm-node, iife, styles, types output by default;
  • UI lib works everywhere and has tree-shaking without any additional configuration;
  • Tools that can automatically test lib in different environment;
  • Has docs and rules, so people don't need to think "How I will make UI lib for my project";
  • Tool for scaffolding;

What benefit for Vuestic?

First of all, we document HOW we make our UI lib, so contributors can easily understand our flow.
Second, we will have a better DX for us.

Extended features

File based build

Similar to Nuxt approach, we can use auto-imports

Let's imagine we have the following structure:

components/
   [component-name]
     tests/
     composables/
     components/
        ChildComponent.vue  // will NOT be exposed, used as child component
     Component.vue // will be exposed as component e.g. `import { Component } from 'vuestic-ui'`
     Component.story.vue
     types.ts
     types.public.ts // Types that will be exposed e.g. `import { type TableHeader } from 'vuestic-ui'`
     styles.scss
composables/
   useColor.ts
   useSomething.public.ts  // Will be exposed as composable, e.g. `import { useSomething } from 'vuestic-ui`
services/
   some code idk 
styles/
   [style-module]
      index.scss // Will be exposed as style module, e.g. import 'vuestic-ui/styles/style-module'
utils/
   file.ts // Will not be exposed

Auto generate main.ts

In main.ts we expose:

  • plugin
  • components
  • composables
  • types
@m0ksem m0ksem added team discussion Feedback wanted epic Feature that is too big to fit in one issue labels Apr 6, 2023
@asvae asvae added ON HOLD We want this, just later epic Feature that is too big to fit in one issue and removed epic Feature that is too big to fit in one issue team discussion Feedback wanted labels Apr 13, 2023
@m0ksem m0ksem removed the ON HOLD We want this, just later label Jul 20, 2023
@m0ksem m0ksem linked a pull request Jul 20, 2023 that will close this issue
15 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
epic Feature that is too big to fit in one issue
Development

Successfully merging a pull request may close this issue.

2 participants