Describe the bug
The Content section is not working on Storybook. Please, check screenshots.

Expected behavior
The following sections loading well:

• Goals and Principles
• Voice and Tone
• Grammar and Mechanics
• Word List

Screenshots

Is your feature request related to a problem? Please describe.

A good feature to have is a check for the total code coverage and diff coverage on PRs with a minimum code coverage threshold set up, this will ensure all new changes are well tested.

Describe the solution you'd like

Integrate a code coverage tool (e.g. istanbul) into the CI pipeline.
Set a minimum code coverage threshold e.g. 60%
Configure the Ci Pipeline to fail if the coverage levels fail below the defined threshold.

Describe the bug

There is a Rollup build error occurring when trying to build the preview. The error message indicates that "default" is not exported by CHANGELOG.md.

To Reproduce

2. Initiate the build process for the project using pnpm run build-storybook in packages/components
3. Encounter error during the build phase.

Expected behavior

The project should build successfully without any errors.

Screenshots

We are looking to transition our build and development setup from Webpack to Vite for our React component library, @rhino-ui/components. This change aims to leverage Vite's faster build times and improved developer experience. Additionally, we want to configure Storybook to use Vite instead of Webpack to maintain consistency and benefit from Vite's advantages.

Current Configuration

Our current setup is heavily reliant on Webpack for bundling our components and running Storybook. The detailed package.json configuration includes various Webpack-specific dependencies and scripts that facilitate our build and development processes.

Desired Outcome

• Remove Webpack and its related configurations, dependencies, and scripts from our project.
• Introduce Vite as our new build tool for the library and configure it to work seamlessly with our existing setup.
• Configure Storybook to run using Vite, ensuring that all existing functionalities remain operational.
• Maintain or improve build and hot module replacement (HMR) performance with minimal to no impact on the development workflow.

Hello everyone,

We're thinking about upgrading our Storybook setup to Component Story Format (CSF) version 3 to take advantage of the new features and improvements it offers. CSF3 is all about making things easier and more efficient for documenting and developing our components, and it sounds like something we could really benefit from.

Is your feature request related to a problem? Please describe.

It would be good to have a code quality checker e.g. CodeClimate that verifies the quality of the code being checked in on each PR.

Describe the solution you'd like

Add CodeClimate to the CI/CD Pipelines.

Is your feature request related to a problem? Please describe.
The issue arises from our current export pattern in index.js, leading to the entire library's inclusion in the project bundle, even if only a few components are used. This can significantly increase the bundle size, impacting application performance.

Describe the solution you'd like
I suggest introducing a modular import option that allows importing components directly from their subpaths, alongside our existing aggregate export approach. For example:

• Direct import: import Alert from '@rhino-ui/components/alert'
• Aggregate import: import { Alert } from '@rhino-ui/components'

This dual approach reduces the bundle size by including only the necessary components, aligning with performance optimization practices. It requires adjusting our package structure to support individual component exports, offering a significant performance benefit without sacrificing convenience.

Customizable Design Tokens

Current Implementation

The design tokens are currently implemented in the packages/design-tokens package. They are built using the style-dictionary library and are consumed by the packages/components package through direct imports.
This implementation has a limitation since the design tokens are not customizable by the consuming application since they are built first before being integrated into the packages/components package.

Concerns to be addressed.

1. We need to ensure that when the developer provides their design tokens, we integrate them to the already "built" component library.
2. We need to provide a seamless integration process to avoid areas of friction during configuration. The customization should be as simple as possible.
3. We need to ensure that the solution works for a large percentage of the built tools with minimal to no configuration.

Proposal 1 (PostCSS Plugin)

The @rhino-ui/design-tokens package will be refactored to contain two different entities:

• The default design tokens source files
• The PostCSS plugin that will consume the design tokens source files and generate the design tokens

Implementation

• The @rhino-ui/design-tokens will be added as a PostCSS plugin in the consuming application's postcss.config.js file:

// postcss.config.js
module.exports = {
  plugins: {
    '@rhino-ui/design-tokens': {}
  }
}

• The consuming application will add directives to the main CSS file to consume the design tokens:

/* main.css */
@rhino-ui variables;

The directive @rhino-ui variables will be used to consume the design tokens in the consuming application's CSS file.

• The consuming application will be able to customize the design tokens by creating a rhino.config.js file in the root of the project:

// rhino.config.js
module.exports = {
  colors: {
    green: {
      50: '#00FF00',
      100: '#00FF00',
      200: '#00EE00',
      300: '#00DD00',
      400: '#00CC00',
      500: '#00BB00',
      600: '#00AA00',
      700: '#009900',
      800: '#008800',
      900: '#007700'
    },
    brand: {
      primary: {
        lightest: "colors.green.50"
      }
    },
  },
  sizes: {
    borderRadius: {
      xs: '2px'
    },
    spacing: {
      xs: '4px'
    },
    fontSize: {
      xs: '12px'
    },
    breakpoints: {
      tablet: '320px'
    }
  }
}

The goal behind having this, is to ensure that the design token values are customizable by the consuming application. This will allow the consuming application to have a more flexible and customizable design system.

Pros

• The design tokens will be customizable by the consuming application
• The design tokens will be more flexible and customizable
• We shall be able to provide the consumer a typing system to allow them easily configure the design tokens in rhino.config.js

Cons

• The consuming application will have to add a rhino.config.js file to customize the design tokens
• The consuming application will need to use PostCSS to configure the design tokens

Proposal 2 (CLI Tool)

The @rhino-ui/design-tokens package will be refactored to contain two different entities:

• The default design tokens source files
• A CLI tool that will consume the design tokens source files and generate the design tokens

Implementation

• The consuming application will be able to customize the design tokens by running the @rhino-ui/design-tokens CLI tool:

npx rhino-ui-design-tokens -c rhino.config.js -o src/output.css --watch

• The consuming application will be able to customize the design tokens by creating a rhino.config.js file in the root of the project. (Refer to the rhino.config.js file in Proposal 1)

CLI Options

• -c or --config: The path to the configuration file
• -o or --output: The path to the output CSS file
• --watch: Watch the design tokens source files for changes and regenerate the design tokens

Pros

• The design tokens will be customizable by the consuming application
• The design tokens will be more flexible and customizable
• The consuming application will not need any additional configuration in their project to customize the design tokens

Cons

• The consuming application will have to use the CLI tool to customize the design tokens
• The consuming application will need to launch the watch mode to regenerate the design tokens when the source files change.

Hello everyone,

We are looking to enhance our library by implementing component testing to ensure the quality and stability of our packages. Since we currently do not have a testing strategy for the React components in our library, we are open to recommendations on tools, frameworks, or practices that could integrate well with our project.

Does anyone have experience or suggestions on the best way to approach testing for this type of library? Any advice, from specific tools to general testing strategies, would be greatly appreciated.

Thank you for your time and contributions!

Is your feature request related to a problem? Please describe.

Add a pipeline to ensure that whenever a new tag is created into the main branch, a publish task is executed to deploy the package to npm.

Describe the solution you'd like
A pipeline that is triggered when a new tag is created in the main branch. This should automatically publish the package to npm.

Description

1. Set up a Pull Request validation pipeline and main branch CI pipeline with GitHub Actions or CircleCI:

• Create workflows for both Pull Request validation and main branch continuous integration using GitHub Actions or CircleCI.
• Ensure that the CI pipeline includes necessary steps for building, testing, and any other relevant tasks.

2. Enforce linting and set up a style guide:

• Implement a linting tool (e.g., ESLint for JavaScript, Flake8 for Python) in the CI pipeline.
• Configure linting rules to follow a specific style guide (e.g., Airbnb style guide for JavaScript).
• Ensure that the CI pipeline fails if linting errors are detected.

3. Add code quality checker with CodeClimate:

• Integrate CodeClimate into the CI pipeline.
• Set up the required CodeClimate configuration file.
• Ensure that the CI pipeline fails if the code quality does not meet the defined standards.

4. Set up code coverage gate on each PR and enforce it:

• Integrate a code coverage tool (e.g., Istanbul for JavaScript, coverage.py for Python) into the CI pipeline.
• Set a minimum code coverage threshold.
• Configure the CI pipeline to fail if the code coverage falls below the defined threshold.

Checklist:

• Pull Request validation pipeline
• Main branch CI pipeline
• Linting enforcement
• Style guide configuration
• CodeClimate integration
• Code coverage gate
• Documentation updates if necessary

Is your feature request related to a problem? Please describe.
It's quite frustrating to manually ensure that our code style remains consistent across various projects. The need to set up ESLint and Prettier for every new project is a repetitive task that slows down development and shifts the focus of code reviews from logic to style.

Describe the solution you'd like
I propose we create our own ESLint and Prettier config modules, specifically @rhino-ui/eslint-config for ESLint configurations and possibly @rhino-ui/ts-config for TypeScript projects. These should be housed in a libs folder at the root of our repository and integrated into our pnpm workspace. This approach will streamline our setup process, ensuring consistency across all projects while minimizing setup time and effort. It's all about making our code as neat and clean as possible, with minimal fuss.

Is your feature request related to a problem? Please describe.
When reviewing code widgets in Storybook, the code is currently not being formatted, which results in it being displayed as plain text. If there's an existing plugin that can be integrated with minimal effort, it would be a valuable addition to our Storybook.

Example: /?path=/docs/about-get-started--docs

Describe the solution you'd like
I would like a feature or tool integrated into Storybook that automatically formats displayed code snippets. This tool should support syntax highlighting for various languages and provide a clear view of the code, similar to what IDEs offer.

Description

We're encountering an issue with the Storybook setup for @rhino-ui/components, which is preventing us from viewing and interacting with the React component library. The problem seems to be related to how SCSS imports are handled.

Error Details

When attempting to start Storybook, the process fails. Below is a screenshot of the error message indicating issues with processing a SCSS file import:

This suggests that the Webpack configuration might be missing an appropriate loader for handling SCSS files, specifically for @import statements within SCSS modules.

Steps to Reproduce

1. Clone the @rhinolabs/rhino-ui repository.
2. Install dependencies with pnpm install.
3. Run pnpm run storybook to start the Storybook development server.
4. The error should be visible in the console output.

Expected Behavior

Storybook should compile and launch without any errors, allowing for the browsing and testing of the React components within the @rhinolabs/rhino-ui library.

Possible Solutions

A potential solution could involve adjusting the Webpack configuration used by Storybook to ensure it includes a loader capable of processing SCSS files. This might mean adding or fine-tuning loaders such as sass-loader to handle @import statements within SCSS modules correctly.

Additional Context

This issue is currently a blocker for the development and testing of components via Storybook. Any help or guidance in resolving this issue would be greatly appreciated.

Is your feature request related to a problem? Please describe.
It would be good to have a Pipeline that runs on any new commit to the main branch

Describe the solution you'd like
The Pipeline should execute the following tasks.

• Lint check
• Tests
• Build

Is your feature request related to a problem? Please describe.

It would be good to have a Pull request pipeline that runs on each PR to main branch.

Describe the solution you'd like
The pipeline should run the following tasks.

• Lint check
• Tests
• Build