Sdk 4.0 WIP (Dont create any new PR use this )

.eslintrc.js

@@ -21,6 +21,7 @@ module.exports = {
     'prettier',
     'chai-friendly',
     'inclusive-language',
+    'eslint-import-resolver-typescript',
   ],
   extends: [
     'eslint:recommended',
@@ -41,6 +42,7 @@ module.exports = {
       ],
       plugins: ['@typescript-eslint'],
       rules: {
+        'valid-jsdoc': 0,
         'default-case': 0,
         'no-undef': 'off',
         'react/prop-types': 'off',
@@ -258,6 +260,9 @@ module.exports = {
   settings: {
     'import/core-modules': ['chai', 'sinon'],
     'import/resolver': {
+      typescript: {
+        alwaysTryTypes: true,
+      },
       node: {
         extensions: ['.js', '.ts'],
         paths: ['src'],

DECORATOR_MIGRATION_ANALYSIS.md

@@ -0,0 +1,163 @@
+# Decorator Migration Analysis and Plan
+
+## Current State Analysis
+
+### Existing Decorators Found
+
+Based on the codebase scan, the following decorator implementations exist:
+
+1. **Legacy Decorators (JavaScript)**:
+   - `packages/@webex/common/src/one-flight.js` - Flight management decorator
+   - `packages/@webex/common/src/while-in-flight.js` - Boolean state management during promises
+
+2. **Modern Decorators (TypeScript)**:
+   - `packages/@webex/common/src/decorators/modern-decorators.ts` - Class-transformer based decorators
+   - `packages/@webex/common/src/decorators/one-flight.ts` - TypeScript version (likely exists)
+   - `packages/@webex/common/src/decorators/usage-examples.ts` - Examples and comparisons
+
+### Usage Patterns
+
+**Current Finding**: The codebase scan revealed **NO ACTIVE USAGE** of the decorator patterns (`@oneFlight`, `@whileInFlight`, etc.) in the current codebase. This indicates:
+
+1. Decorators may have been deprecated/removed in previous migrations
+2. The implementations exist as legacy code or for future use
+3. The modern decorator system is already partially implemented but not yet adopted
+
+## Migration Strategy
+
+### Phase 1: Complete Modern Decorator System ✅
+
+The modern decorator system is already well-designed in `modern-decorators.ts`:
+
+- `@WebexCacheable` - Replaces `@oneFlight` with TTL caching
+- `@WebexValidate` - Adds validation support
+- `@WebexRetry` - Network retry functionality
+- `@WebexTimeout` - Operation timeout handling
+- Base classes: `WebexConfigurable`, `WebexRequest`, `WebexResponse`
+
+### Phase 2: Migration Plan for Active Usage (If Found)
+
+Since no active usage was found, the following would be the approach IF decorators were being used:
+
+#### 2.1 One-Flight Pattern Migration
+
+```javascript
+// BEFORE (Legacy)
+@oneFlight
+async fetchData(id) {
+  return await this.api.get(`/data/${id}`);
+}
+
+// AFTER (Class-Transformer)
+@WebexCacheable({ttl: 30000}) // 30 second cache
+@WebexValidate()
+async fetchData(id: string): Promise<DataResponse> {
+  const response = await this.api.get(`/data/${id}`);
+  return plainToClass(DataResponse, response);
+}
+```
+
+#### 2.2 While-In-Flight Pattern Migration
+
+```javascript
+// BEFORE (Legacy)
+@whileInFlight('isLoading')
+async performAction() {
+  return await this.service.execute();
+}
+
+// AFTER (Class-Transformer + Custom)
+@WebexLoadingState('isLoading') // Custom decorator to be created
+@WebexValidate()
+async performAction(): Promise<ActionResult> {
+  const result = await this.service.execute();
+  return plainToClass(ActionResult, result);
+}
+```
+
+### Phase 3: Required Additions
+
+To complete the migration system, we need to add:
+
+1. **Loading State Decorator** (equivalent to `@whileInFlight`)
+2. **Metrics/Logging Decorators**
+3. **Error Handling Decorators**
+
+## Implementation Status
+
+### ✅ Completed
+
+- Modern decorator framework with class-transformer
+- Caching decorator (`@WebexCacheable`)
+- Validation decorator (`@WebexValidate`)
+- Retry and timeout decorators
+- Base configurable classes
+- Usage examples and documentation
+
+### 🔄 In Progress/Needed
+
+- Loading state decorator to replace `@whileInFlight`
+- Migration of any existing usage (none found currently)
+- Integration with existing Webex plugin architecture
+
+### ❌ TODOs - Decorators That Cannot Be Easily Migrated
+
+1. **Complex State Management Decorators**
+   - Decorators that directly manipulate component/plugin state
+   - **Reason**: Class-transformer is focused on data transformation, not state management
+   - **Solution**: Use dedicated state management patterns (Redux, MobX, or custom)
+
+2. **Framework-Specific Decorators**
+   - Decorators tightly coupled with Ampersand or other legacy frameworks
+   - **Reason**: Different lifecycle and architecture assumptions
+   - **Solution**: Refactor to use modern React/Vue patterns or custom hooks
+
+3. **Runtime Dynamic Decorators**
+   - Decorators that modify behavior based on runtime configuration
+   - **Reason**: Class-transformer decorators are compile-time
+   - **Solution**: Use factory patterns or higher-order functions
+
+## Next Steps
+
+### Immediate Actions Needed
+
+1. **Complete Loading State Decorator**:
+
+   ```typescript
+   export function WebexLoadingState(propertyName: string): MethodDecorator {
+     // Implementation to set boolean state during async operations
+   }
+   ```
+
+2. **Create Migration Guide**:
+   - Document patterns for teams to follow
+   - Provide before/after examples
+   - Add linting rules to catch old patterns
+
+3. **Update Build System**:
+   - Ensure class-transformer is properly configured
+   - Add reflect-metadata support where needed
+
+### Long-term Maintenance
+
+1. **Monitor for Usage**:
+   - Set up linting rules to catch old decorator usage
+   - Add deprecation warnings to legacy decorators
+
+2. **Documentation**:
+   - Update developer guides
+   - Add migration examples to common patterns
+
+3. **Testing**:
+   - Ensure all decorator functionality is properly tested
+   - Add integration tests for class-transformer usage
+
+## Conclusion
+
+The decorator migration is largely **COMPLETE** with no active usage found in the current codebase. The modern class-transformer system is well-implemented and ready for adoption. The main remaining work is:
+
+1. Adding missing decorator patterns (loading state)
+2. Ensuring the system is properly documented for new development
+3. Adding safeguards to prevent regression to old patterns
+
+The migration infrastructure is solid and follows modern TypeScript/JavaScript patterns with proper typing, validation, and transformation capabilities.