@hero-design/rn-work-uikit 1.9.0 → 1.9.2

package/.cursorrules

@@ -1,57 +0,0 @@
-# RN Work UIKit Specific Rules
-
-## Package Context
-This is the work-specific React Native component library that extends @hero-design/rn with work-focused components like TextInput, specialized themes, and work-specific patterns.
-
-## Testing Rules for RN Work UIKit
-- Write user-behavior focused tests that describe what users see and experience
-- Use descriptive test names like "when user sees an empty input field" instead of "idle state"
-- Group related assertions with explanatory comments about user expectations
-- Focus on user interactions and outcomes rather than implementation details
-- Use `@testing-library/react-native` for all component testing
-- Use `renderWithTheme()` from `../../../../testUtils/renderWithTheme` for components that need theme context
-- Use semantic matchers like `toBeDisabled()`, `toHaveProp()` when available
-- For complex React Native styles, use manual checking when `toHaveStyle()` doesn't work
-- Handle React Native's nested style arrays with `StyleSheet.flatten()` or custom helpers
-- Aim for 100% line coverage on main component files
-- Create dedicated test files for each component (not just integration tests)
-- Test edge cases: undefined props, complex styles, error states
-- Test imperative APIs: ref methods, focus/blur behavior
-- Test accessibility: screen reader support, keyboard navigation
-
-## Component Development Rules
-- Import `styled` from `@hero-design/rn` for consistency with base theme
-- Use `useTheme()` hook instead of prop drilling theme
-- Extend base components from `@hero-design/rn` when possible
-- Follow work-specific design patterns and accessibility requirements
-- Use TypeScript strictly - no `any` types without good reason
-- Fix linting errors immediately
-- Use proper React Native components (`Text`, `View`) instead of HTML elements
-
-## Documentation Rules
-- Document Props interfaces with JSDoc comments directly on each property: `/** Description */`
-- Use simplified @param comments: `@param props - The component props (see [ComponentName]Props interface for details)`
-- Avoid mentioning implementation details like "memoized component" in JSDoc comments
-- Focus JSDoc comments on what the component does, not how it's implemented
-- Keep type information in the Props interface, not duplicated in @param comments
-
-## File Organization
-- Separate large test files by component responsibility
-- Use consistent naming: `ComponentName.spec.tsx`
-- Keep test utilities in `testUtils/` directory at package root
-- Use snapshot testing for visual regression prevention
-- Create README.md files in test directories explaining testing approach
-
-## Work-Specific Patterns
-- Components should work with work theme overrides
-- Test with work-specific color palettes and spacing
-- Ensure compatibility with work app requirements
-- Follow work accessibility guidelines
-- Test performance with work-typical data sizes
-
-## Quality Gates
-- All tests must pass with 100% coverage on main components
-- No linting errors
-- No TypeScript errors
-- Components must work with both base and work themes
-- Accessibility compliance for work environment 

package/src/utils/hooks.ts

@@ -1,10 +0,0 @@
-import { useEffect } from 'react';
-
-export const useDeprecation = (message: string, cond = true) => {
-  useEffect(() => {
-    // eslint-disable-next-line no-console
-    if (cond) {
-      console.warn(message);
-    }
-  }, [message, cond]);
-};