A component library for sharing UI components across Selfeesas company projects. Built on Vue 3 and Quasar, optimized for Vite.
npm install @selfeesas/shared-componentsA component library for sharing UI components across Selfeesas company projects. Built on Vue 3 and Quasar, optimized for Vite.
---
- 🔁 Reusable components for multiple projects
- ⚡ Built on Vue 3 + Quasar + Vite
- 📚 Storybook for visual documentation
- 🎯 TypeScript support
- ✅ Installable via npm
- 🔧 Automated CI/CD, including Semantic Release, SonarCloud, and Storybook GH Pages
---
``bash`
npm install @selfeesas/shared-componentsor
yarn add @selfeesas/shared-components
> Ensure that vue, vue-router, and quasar are already installed in your project.
---
| Package | Version |
| ---------- | --------- |
| Vue | ^3.5.16 |^4.5.1
| Vue Router | |^2.18.1
| Quasar | |
---
`ts`
import { SharedButton } from '@selfeesas/shared-components'
Now you can use the components in your Vue templates:
`vue`
⚠️ Important: To ensure components render correctly, you must import the styles.
Add the following import in your project's root file (e.g., main.ts or main.js):
`bash`
import "@selfeesas/shared-components/dist/assets/shared-components.css";
---
> Examples are available in Storybook:
> 🔗 https://selfeesas.github.io/SharedUI
- NavButton
-
-
-
- and more...
---
Run locally:
`bash`
npm run storybook
Build:
`bash`
npm run build-storybook
---
`bash`
npm run lint # Run ESLint checks
npm run lint:fix # Fix ESLint errors
npm run format # Run Prettier + ESLint fix
---
- GitHub Actions: Linting, building, and deploying Storybook
- Semantic Release: Automated version releases
- SonarCloud: Static code analysis
---
The CI/CD pipeline is defined in .github/workflows/main.yml and automates linting, building, testing, versioning, and deployment. It uses GitHub Actions and is triggered on:
- Pushes to the main branchmain
- Pull requests targeting the branch
- Releases created in the repository
#### Pipeline Jobs
1. Lint and Build:
- Checks out the code and sets up Node.js (v20).
- Installs dependencies with npm ci.npm run lint -- --max-warnings=0
- Runs ESLint with to enforce code quality.npm run build
- Builds the package with .
2. Semantic Release (runs only on main branch):cycjimmy/semantic-release-action
- Uses to automate versioning and releases.fix
- Analyzes commit messages following the Conventional Commits format:
- : Patches (e.g., 1.0.1)feat
- : Minor updates (e.g., 1.1.0)BREAKING CHANGE
- : Major updates (e.g., 2.0.0)package.json
- Automatically updates the version in .CHANGELOG.md
- Generates or updates the based on commit messages.NPM_TOKEN
- Publishes the package to npm using the .
- Creates a GitHub release with the new version.
3. Deploy Storybook (runs only on main branch):npx storybook build
- Builds Storybook with .peaceiris/actions-gh-pages
- Deploys the static Storybook site to GitHub Pages using .
4. SonarCloud:
- Runs static code analysis with SonarCloud to detect bugs, vulnerabilities, and code smells.
- Requires SONAR_TOKEN for authentication.
#### How to Work with the Pipeline
- Commit Messages: Use Conventional Commits to ensure Semantic Release works correctly. See the Conventional Commits section below for details.
- Local Testing: Before pushing, run npm run lint, npm run build, and npm run storybook locally to catch issues early.CHANGELOG.md
- Changelog: The is auto-generated by Semantic Release. Do not edit it manually.main
- Storybook Deployment: Updates to Storybook are automatically deployed to https://selfeesas.github.io/SharedUI on branch pushes.
#### Troubleshooting
- Pipeline Fails on Lint: Run npm run lint:fix locally and commit fixes.storybook-static
- Semantic Release Skips Versioning: Ensure commit messages follow Conventional Commits. Check the pipeline logs for details.
- Storybook Deployment Fails: Verify the directory is generated correctly with npm run build-storybook.SONAR_TOKEN
- SonarCloud Issues: Check SonarCloud logs for specific issues and ensure is valid.
To ensure proper versioning and changelog generation, all commits must follow the Conventional Commits specification. This standardizes commit messages to make them machine-readable for Semantic Release.
#### Commit Message Structure
A commit message consists of a type, optional scope, optional ! for breaking changes, and a description. The format is:
`
[optional body]
[optional footer(s)]
- type: Indicates the nature of the change (e.g., fix, feat, docs, style, refactor, test, chore).SharedButton
- scope: Specifies the part of the codebase affected (e.g., , SharedModal).BREAKING CHANGE:
- !: Denotes a breaking change (triggers a major version bump).
- description: A concise summary of the change.
- body: Additional context (optional).
- footer: Metadata like or issue references (optional).
#### Examples
- Fix (Patch Release):
`
fix(SharedButton): resolve alignment issue in dark mode
- Triggers a patch release (e.g., 1.0.0 → 1.0.1).
- Feature (Minor Release):
`
feat(SharedDropdown): add support for multi-select
- Triggers a minor release (e.g., 1.0.0 → 1.1.0).
- Breaking Change (Major Release):
`
feat(SharedModal): add new props for customization
BREAKING CHANGE: removed deprecated prop`
- Triggers a major release (e.g., 1.0.0 → 2.0.0).
- Documentation Update:
`
docs(readme): update installation instructions
- Does not trigger a release but updates the changelog.
- Scoped Chore:
`
chore(deps): update Quasar to 2.18.1
- Does not trigger a release but is included in the changelog.
#### Best Practices
- Keep descriptions concise and meaningful.
- Use the ! or BREAKING CHANGE: footer for any change that requires users to update their code.fix: bug
- Include a scope when possible to clarify the affected component or module.
- Avoid generic messages like —be specific about the change.git commit -m "type(scope): description"` or use a tool like Commitizen for guided commit messages.
- Run
For full details, refer to the Conventional Commits specification.
---
MIT © Selfeesas
---