@namuna-nur/ui-kit 1.0.2 → 1.0.5

package/README.md

@@ -1,84 +1,4 @@
 
-- [Technologies Used](#technologies-used)
-- [Project Structure](#project-structure)
-- [Prerequisites](#prerequisites)
-- [Local Setup](#local-setup)
-- [Development Approach](#development-approach)
-  - [Development Patterns](#development-patterns)
-  - [Atomic Design Principles](#atomic-design-principles)
-  - [Design Tokens](#design-tokens)
-  - [Naming Conventions](#naming-conventions)
-  - [Branch Naming Conventions](#branch-naming-conventions)
-  - [Scripts](#scripts)
-- [Git Hooks](#git-hooks)
-  - [pre-commit](#pre-commit)
-  - [commit-msg](#commit-msg)
-    - [Guidelines](#guidelines)
-    - [Examples](#examples)
-    - [Rules](#rules)
-- [Copyright](#copyright)
-
-## Technologies Used
-- **[React](https://react.dev/)**: JavaScript library for building user interfaces
-- **[TypeScript](https://www.typescriptlang.org/)**: Provides static typing for JavaScript to enhance development quality
-- **[Tailwind CSS](https://tailwindcss.com/)**: Utility-first CSS framework for rapid UI development
-- **[Radix UI](https://www.radix-ui.com/)**: Library for building accessible React components
-- **[Storybook](https://storybook.js.org/)**: UI development environment to build and document components in isolation
-- **[React Testing Library](https://testing-library.com/)**: For testing React components
-
-## Project Structure
-
-The project's folder structure is organized as follows:
-
-```sh
-├── public            # Public assets such as images and icons
-└── src               # Main source code directory
-    ├── _shared       # Shared components
-    ├── atoms         # Basic building blocks of the UI (Button, Input, etc.)
-    ├── molecules     # Combination of atoms (InputGroup, TabGroup, etc.)
-    ├── organisms     # Complex components (Form, Modal, etc.)
-    ├── hooks         # Custom React hooks
-    ├── tokens        # Design tokens (colors, typography, spacing, etc.)
-    └── utils         # Utility functions 
-```
-
-## Prerequisites
-- **[Node.js](https://nodejs.org/)**: v20.x or higher
-- **NPM**: v10.x or higher
-
-## Local Setup
-
-1. **Clone the Repository**
-   ```sh
-   git clone git@git.devsymfony.io:Namuna/ui-kit.git
-   cd ui-kit
-   ```
-
-2. **Install Dependencies**
-   ```sh
-   npm install
-   ```
-
-3. **Launch Storybook**
-   ```sh
-   npm dev
-   ```
-   This will start the Storybook at `http://localhost:6006`
-
-4. **Run Tests**
-   ```sh
-   npm test
-   ```
-   This will run the test suite to verify that everything is working as expected.
-
-5. (Optional) **Run Test Coverage**
-   ```sh
-   npm run test:coverage:ui
-   ```
-   This will check the current test coverage using `istanbul` to visually identify uncovered lines of code.
-
-You are all set! **Happy coding!**
-
 ## Installation (as NPM Package)
 
 Install the UI Kit in a consuming project:
@@ -113,6 +33,7 @@ You can also import category entry points for potentially smaller bundles:
 import { Button } from '@namuna-nur/ui-kit/atoms'
 import { TabGroup } from '@namuna-nur/ui-kit/molecules'
 ```
+You are all set! **Happy coding!**
 
 ### Styles & Tailwind Setup
 This kit relies on Tailwind utility classes. In the consumer project:
@@ -194,145 +115,6 @@ Yes—import only what you need.
 **ESM only?**  
 Yes. If you need CJS, use a transpilation step in your app bundler.
 
-**Storybook usage?**  
-Clone the repo and run `npm run storybook:dev` for full docs.
-
-
-## Development Approach
-
-This project follows the **Atomic Design** methodology for building reusable UI components. The Atomic Design pattern encourages breaking down the UI into small, reusable parts (atoms, molecules, organisms, etc.), ensuring a consistent and maintainable codebase. More details on Atomic Design can be found [here](https://bradfrost.com/blog/post/atomic-web-design/).
-
-**Storybook** is used extensively to develop and document components in isolation. Storybook helps visualize components, understand their states and variants, and provides a seamless way to test each component individually before integration. You can read more about testing with Storybook [here](https://storybook.js.org/docs/writing-tests/).
-
-### Development Patterns
-- **Atomic Design Pattern**: The components are divided into atoms, molecules, organisms, and templates. This approach facilitates better reusability and maintainability of the code.
-- **Component Isolation in Storybook**: Each component is built and tested independently using Storybook to ensure that they behave correctly in isolation. This helps reduce bugs when integrating components together.
-- **Testing**: We use a **React Testing Library** for unit tests. Writing comprehensive tests ensures the stability of the system and catches regressions early.
-- **Best Practices**: Code should follow established best practices, including clear separation of concerns, meaningful naming conventions, and usage of utility classes from **Tailwind CSS** for styling.
-
-### Atomic Design Principles
-
-- **Atoms**: The basic building blocks of the UI, such as buttons, labels, and input fields. Examples:
-  - `Button`: A reusable button element with different styles (e.g., primary, secondary).
-  - `Input`: A text input field with different states (e.g., disabled, active).
-- **Molecules**: Groupings of atoms that work together as a unit, like forms or toolbars. Examples:
-  - `InputGroup`: A label and input field grouped together.
-  - `DropdownGroup`: A dropdown combined with a button for more specific actions.
-- **Organisms**: More complex components that consist of molecules and/or atoms to form a section of a UI. Examples:
-  - `Form`: A complete form component with multiple inputs, buttons, and labels.
-  - `Navbar`: A navigation bar with links, search input, and user menu.
-
-### Design Tokens
-
-To maintain consistent styling across components, we use design tokens. Tokens encapsulate values for colors, typography, spacing, and more, and are defined centrally in the `tokens` directory, as well as local tokens follow `<component>.tokens.ts` naming pattern. 
-
-### Naming Conventions
-- **Component Files**: Component files should be named using PascalCase, e.g., `InputField.tsx`, `DropdownMenu.tsx`.
-- **CSS Classes**: Use `kebab-case` for class names, e.g., `.button-primary`.
-- **Props and Variables**: Use camelCase for props and variables, e.g., `isDisabled`, `inputValue`.
-- **Test Files**: The test files should have the same name as the component they test, with `.test.tsx` as a suffix, e.g., `Button.test.tsx`.
-
-### Branch Naming Conventions
-Branch names should be descriptive and follow a consistent format to ensure that they clearly convey the purpose of the branch. The format to be used is:
-
-```
-<type>/<NUR-ticket>_<description>
-```
-
-- **type**: The type of work the branch is intended for. The common types are:
-  - `feature` (e.g., `feature/NUR-123_new-navbar`): New features.
-  - `fix` (e.g., `fix/NUR-456_bugfix-modal`): Bug fixes.
-  - `chore` (e.g., `chore/NUR-789_update-dependencies`): Maintenance tasks.
-  - `hotfix` (e.g., `hotfix/NUR-101_critical-fix`): Critical issues that need an immediate fix.
-- **JIRA Ticket**: Always include the Task Manager ticket identifier to associate branches with tasks.
-- **Description**: A short description of the branch's purpose separated from Task Manager ticket number with underscore (`_`). It should be lowercase and use hyphens instead of spaces.
-
-Examples:
-- `feature/NUR-110_add-login-button`
-- `fix/NUR-220_correct-header-issue`
-- `chore/NUR-320_refactor-storybook-setup`
-
-### Scripts
-
-Here are some of the commonly used scripts available in `package.json`:
-
-- **Development**:
-  - `dev`: Starts Storybook locally for component development.
-  - `build`: Builds the `Storybook` documentation for deployment.
-
-- **Linting & Formatting**:
-  - `prepare`: Prepares `husky` hooks.
-  - `format`: Checks the formatting of `TypeScript` files using `Prettier`.
-  - `format:fix`: Automatically formats `TypeScript` files.
-  - `lint`: Runs `ESLint` to find code issues.
-  - `lint:fix`: Attempts to fix code issues automatically.
-
-- **Testing**:
-  - `test`: Runs unit and integration tests using `Vitest` with a basic reporter.
-  - `test:watch`: Watches for changes and runs tests interactively.
-  - `test:coverage`: Runs tests and provides coverage reports.
-  - `test:coverage:ui`: Runs tests and serves a UI for viewing coverage reports.
-
-## Git Hooks
-
-To maintain code quality and consistency across the development team, we use Git Hooks with [Husky](https://typicode.github.io/husky) to automate certain checks before committing code.
-
-### [pre-commit](/.husky/pre-commit)
-
-The `pre-commit` hook is set up to run the following commands in sequence:
-
-```sh
-npm run format            # Runs the code formatter to maintain code style guidelines
-npm run lint              # Runs ESLint to identify any coding style issues
-npm run test              # Executes all unit tests
-npm run build             # Compiles TypeScript files to check for type errors
-npm run storybook:build   # Builds Storybook
-```
-
-Check out **Husky** [docs](https://typicode.github.io/husky/how-to.html#adding-a-new-hook) for instructions on how to add new hooks.
-
-### [commit-msg](./husky/commit-msg)
-
-The `commit-msg` hook ensures that all commit messages follow the conventional commit style as enforced by [commitlint](https://github.com/conventional-changelog/commitlint). This helps maintain a consistent format for commit messages, which makes it easier to read and understand the project's history.
-
-#### Guidelines
-
-According to the rules specified in `commitlint.config.ts`, commit messages should be structured in the following format:
-
-```
-<type>(optional scope): <subject>
-```
-
-- **type**: Specifies the purpose of the commit. Common types include:
-  - `feat`: A new feature
-  - `fix`: A bug fix
-  - `chore`: Routine tasks, like maintenance
-  - `docs`: Changes to documentation
-  - `style`: Code style changes that do not affect the code's logic
-  - `refactor`: A code change that neither fixes a bug nor adds a feature
-  - `test`: Adding or modifying tests
-  - `perf`: Changes that improve performance
-  - `poc`: Reserved for POCs
-
-- **scope**: Specifies the task number from Task Manager, e.g., `NUR-123`
-
-- **subject**: A brief description of the changes. It should be imperative and in lowercase.
-
-#### Examples
-
-- `feat(NUR-123): add new button component`
-- `fix(NUR-123): correct route mapping issue`  
-- `chore(NUR-123): update dependencies`
-feat(86et1d8y6): add income tax on dividends and interest
-#### Rules
-
-The rules from `commitlint.config.ts` include:
-- **Header Length**: Commit message headers must not exceed 100 characters
-- **Type and Scope**: Only the specified types are allowed, and scopes must start with `NUR-`
-- **Case Sensitivity**: The type and scope should always be lowercase
-
-To learn more, refer to the **Commitlint** [docs](https://commitlint.js.org/#/).
-
 ## Copyright
 This project is solely owned by (c) Namuna - NUR. All rights reserved.