The application is currently in a transitional state with regard to shared components:
-
Package Infrastructure:
- Shared components are defined in
../shared-tools/packages/ - Basic package.json files exist for:
- dropdown-menu
- loading-spinner
- popover
- route-transition
- The packages are referenced in the application's package.json
- Shared components are defined in
-
Current Approach:
- Component files are still in the local project (
src/components/) - Imports are using the local components (
import LoadingSpinner from '@/components/LoadingSpinner') - Components have deprecation comments mentioning the future shared imports
- Component files are still in the local project (
-
Issues Encountered:
- Attempted migration to shared components via the
@ix/*import path - Build failures due to module resolution issues
- The verification script works, but actual import paths failed
- Attempted migration to shared components via the
- Create TypeScript Source Files:
- For each component in
../shared-tools/packages/<component>/src/index.tsx - Create proper interfaces and exports
- Example for LoadingSpinner:
- For each component in
// ../shared-tools/packages/loading-spinner/src/index.tsx
import React from 'react';
export interface LoadingSpinnerProps {
size?: 'sm' | 'md' | 'lg';
color?: 'primary' | 'white' | 'gray';
className?: string;
}
export function LoadingSpinner({
size = 'md',
color = 'primary',
className = ''
}: LoadingSpinnerProps) {
// Implementation here
}-
Set Up TypeScript Configs:
- Add tsconfig.json to each package
- Configure for React and module exports
- Ensure dist directory is properly set up
-
Implement Build Process:
- Ensure
npm run buildworks in each package - Verify compiled output in dist/
- Ensure
-
Add Test Files:
- Create Jest tests for each component
- Test rendering and props
-
Create Documentation:
- README.md for each component
- Usage examples
-
Test Compilation:
- Ensure TypeScript compilation works
- Validate the output matches expectations
-
Update One Component at a Time:
- Start with LoadingSpinner
- Test in isolation before integrating
- Verify in the main application
-
Update Import Statements:
- Change from:
import LoadingSpinner from '@/components/LoadingSpinner';
- To:
import { LoadingSpinner } from '@ix/loading-spinner';
-
Run Verification:
- Use
npm run verify:importsto check consistency - Run build tests after each component
- Use
-
Dependency Check:
- Verify no local code uses the components directly
- Check for any specific customizations
-
Remove Local Files:
- Delete local component files only after full verification
- Document removal in commit messages
Each shared component should follow this structure:
loading-spinner/
├── dist/ # Compiled output
├── src/ # TypeScript source
│ └── index.tsx # Component definition
├── package.json # Package metadata
├── tsconfig.json # TypeScript configuration
└── README.md # Component documentation
{
"name": "@ix/loading-spinner",
"version": "0.1.0",
"description": "Loading Spinner component for IX projects",
"main": "dist/index.js",
"types": "dist/index.d.ts",
"files": [
"dist",
"README.md"
],
"scripts": {
"build": "tsc",
"test": "jest",
"lint": "eslint . --ext .ts,.tsx",
"prepublishOnly": "npm run build"
},
"peerDependencies": {
"react": ">=17.0.0",
"react-dom": ">=17.0.0"
}
}The verify-component-imports.js script should be run before each build to ensure consistency:
npm run verify:importsIf you encounter build issues during migration:
-
Module Resolution Errors:
- Verify the shared component exists and is built
- Check that package.json references are correct
- Look for path issues in import statements
-
TypeScript Errors:
- Ensure interfaces match between components
- Check for missing exports or wrong export syntax
-
Temporary Rollback Process:
- If critical issues arise, revert to local components
- Document what failed for future attempts
Key scripts for managing this migration:
-
setup-shared-components.js:
- Updates package.json with local file references
- Creates symlinks if needed
-
verify-component-imports.js:
- Checks for inconsistent import usage
- Validates shared component structure
-
migrate-imports.js:
- Updates import statements to use modular imports
- Can be run on specific files or directories
For the 12 agents working on this project:
-
Component Library Lead (2 agents):
- Set up TypeScript configs
- Implement build process
- Create base component structure
-
Component Developers (6 agents):
- LoadingSpinner team (2)
- Popover team (2)
- RouteTransition team (1)
- DropdownMenu team (1)
-
Integration Team (2 agents):
- Verify application imports
- Test in main application
- Coordinate with component teams
-
Documentation & Testing (2 agents):
- Write component documentation
- Create test suites
- Verify proper coverage
-
Week 1: Setup and Library Infrastructure
- Create all necessary files and configs
- Set up build process
- Initial component implementations
-
Week 2: Component Testing
- Test components in isolation
- Fix any issues discovered
- Document component APIs
-
Week 3: Migration
- Update imports in main application
- Test integration
- Remove local components
After migration, verify the following:
-
Build succeeds with no errors:
npm run build
-
All tests pass:
npm test -
Components render correctly in the application:
- Start the application and visually verify components
- Check error console for any warnings/errors
-
Import verification passes:
npm run verify:imports