|
| 1 | +--- |
| 2 | +mode: agent |
| 3 | +--- |
| 4 | + |
| 5 | +# Mixcore JavaScript SDK Extraction & Modularization Specification |
| 6 | + |
| 7 | +## Objective |
| 8 | + |
| 9 | +Extract all "shared", "base", and "apis" JavaScript/TypeScript code from `@mixcore/mix.spa.portal` and refactor them into a new, independent, and future-proof SDK repository: `mixcore/javascript-sdk`. The SDK must be modular, highly reusable, and suitable for internal, external, and third-party consumers (web, Node.js, microfrontends, plugins, etc.). |
| 10 | + |
| 11 | +--- |
| 12 | + |
| 13 | +## Directory Structure & Tooling |
| 14 | + |
| 15 | +- Use a monorepo structure with [Nx](https://nx.dev/), [Lerna](https://lerna.js.org/), or [Yarn Workspaces] if multiple packages are expected; otherwise, organize under `src/`. |
| 16 | +- Proposed directory structure: |
| 17 | + ``` |
| 18 | + mixcore/javascript-sdk/ |
| 19 | + ├── packages/ |
| 20 | + │ ├── shared/ # Utilities, helpers, constants |
| 21 | + │ ├── base/ # Base classes, abstract models, interfaces |
| 22 | + │ └── apis/ # API clients, endpoint wrappers, schema types |
| 23 | + ├── tests/ # Cross-package/unit/integration tests |
| 24 | + ├── README.md |
| 25 | + ├── package.json |
| 26 | + └── nx.json / lerna.json (if using monorepo tool) |
| 27 | + ``` |
| 28 | +- Prefer TypeScript for new code; convert JS to TS where feasible. |
| 29 | +
|
| 30 | +--- |
| 31 | +
|
| 32 | +## Extraction & Refactoring Instructions |
| 33 | +
|
| 34 | +1. **Audit Source Code** |
| 35 | + - Locate all code in `@mixcore/mix.spa.portal` related to "shared", "base", and "apis". |
| 36 | + - Include all `.js`, `.ts`, type declaration files, and related JSON/configs if directly used by these modules. |
| 37 | + - Exclude SPA-specific or UI-coupled logic. |
| 38 | +
|
| 39 | +2. **Migration** |
| 40 | + - Move the identified code into the corresponding packages/folders in `mixcore/javascript-sdk`. |
| 41 | + - Maintain original directory structure as much as possible for clarity. |
| 42 | + - Refactor imports/exports to use package-relative paths. |
| 43 | +
|
| 44 | +3. **Decoupling & Configuration** |
| 45 | + - Remove or abstract any SPA-coupled dependencies (e.g., window, document, SPA-specific stores). |
| 46 | + - Externalize configuration (endpoints, tokens, etc.) using environment variables or injectable configs. |
| 47 | + - Ensure all modules are framework-agnostic (no direct Vue/React/Angular dependencies). |
| 48 | +
|
| 49 | +4. **Build Outputs** |
| 50 | + - Configure builds for both ESM and CJS outputs for maximal compatibility. |
| 51 | + - Generate TypeScript type declarations (`.d.ts`). |
| 52 | +
|
| 53 | +5. **Testing** |
| 54 | + - Write or migrate unit/integration tests for all public APIs. |
| 55 | + - Use a test runner compatible with monorepo (e.g., Jest, Vitest). |
| 56 | +
|
| 57 | +6. **Documentation** |
| 58 | + - Document each package/module with clear usage examples. |
| 59 | + - Add migration guides for teams adopting the SDK. |
| 60 | +
|
| 61 | +7. **Versioning & Publishing** |
| 62 | + - Use semantic versioning (SemVer) for each package or the overall SDK. |
| 63 | + - Configure CI/CD pipelines for linting, testing, building, and publishing (npm, GitHub Packages, etc.). |
| 64 | +
|
| 65 | +8. **Backward Compatibility** |
| 66 | + - Provide clear migration notes for dependent projects. |
| 67 | + - Optionally, maintain compatibility layers or adapters if needed. |
| 68 | +
|
| 69 | +--- |
| 70 | +
|
| 71 | +## Usage Scenarios Supported |
| 72 | +
|
| 73 | +- **Web Applications:** Import shared logic/API clients directly. |
| 74 | +- **Node.js Backends:** Use SDK for server-side scripting, CLI, automation. |
| 75 | +- **Microfrontends:** Share core logic across isolated frontend apps. |
| 76 | +- **Third-party Plugins/Extensions:** Allow external devs to build on Mixcore APIs safely. |
| 77 | +- **Test Automation:** Leverage SDK’s API clients and types. |
| 78 | +
|
| 79 | +--- |
| 80 | +
|
| 81 | +## Security & Compliance |
| 82 | +
|
| 83 | +- No secrets or credentials are hardcoded. All sensitive config must be injected at runtime. |
| 84 | +- API clients must sanitize all inputs/outputs and handle errors gracefully. |
| 85 | +- License the SDK under Mixcore Community License (MCL) or compatible OSS license with clear attribution. |
| 86 | +
|
| 87 | +--- |
| 88 | +
|
| 89 | +## Example SDK Package Metadata (`package.json`) |
| 90 | +
|
| 91 | +```json |
| 92 | +{ |
| 93 | + "name": "@mixcore/shared", |
| 94 | + "version": "1.0.0", |
| 95 | + "main": "dist/index.js", |
| 96 | + "module": "dist/index.esm.js", |
| 97 | + "types": "dist/index.d.ts", |
| 98 | + "license": "SEE LICENSE IN LICENSE", |
| 99 | + "repository": "https://github.com/mixcore/javascript-sdk" |
| 100 | +} |
| 101 | +``` |
| 102 | + |
| 103 | +--- |
| 104 | + |
| 105 | +## Deliverables |
| 106 | + |
| 107 | +- Extracted and refactored source code in `mixcore/javascript-sdk` |
| 108 | +- Complete documentation and migration guides |
| 109 | +- CI/CD configuration for automated testing and publishing |
| 110 | +- (Optional) Compatibility adapters for legacy consumers |
| 111 | + |
| 112 | +--- |
| 113 | + |
| 114 | +## Reference |
| 115 | + |
| 116 | +- Source: [@mixcore/mix.spa.portal](https://github.com/mixcore/mix.spa.portal) |
| 117 | +- Target: [mixcore/javascript-sdk](https://github.com/mixcore/javascript-sdk) |
| 118 | +- Platform: [Mixcore CMS Overview](https://github.com/mixcore/mix.core) |
| 119 | + |
| 120 | +--- |
| 121 | + |
| 122 | +## Approval |
| 123 | + |
| 124 | +This spec serves as the single source of truth for engineering, QA, and product teams for the extraction and modularization process. All future changes and implementation tasks must align with the requirements above. |
| 125 | + |
| 126 | +# Detailed Context for Extraction of Shared, Base, and API Code |
| 127 | + |
| 128 | +## 1. Extraction Scope and Philosophy |
| 129 | + |
| 130 | +- **Goal:** Create a future-proof, reusable, and framework-agnostic JavaScript/TypeScript SDK that contains all utilities, base models, and API integrations previously coupled to the SPA Portal. |
| 131 | +- **Principle:** All code in the SDK must be usable outside the context of any specific frontend framework or application. |
| 132 | + |
| 133 | +--- |
| 134 | + |
| 135 | +## 2. What to Extract |
| 136 | + |
| 137 | +- All code (in JavaScript or TypeScript) that is: |
| 138 | + - **Shared:** Utility functions, constants, validators, formatters, date/time helpers, i18n, etc. |
| 139 | + - **Base:** Abstract classes, data models, DTOs, interfaces, inheritance hierarchies. |
| 140 | + - **APIs:** API client classes/functions, HTTP request wrappers, endpoint schema types, authentication handlers, API error types, and response mappers. |
| 141 | +- **Include:** All related type definitions, interfaces, enums, and any utility that is referenced by shared/base/api modules. |
| 142 | +- **Configuration:** Move any constants or config variables (e.g., API endpoints, keys) to injectable/configurable APIs. Do not hardcode environment details. |
| 143 | +- **Tests:** Migrate relevant unit and integration tests. If tests are tightly coupled to SPA, adapt them for SDK context. |
| 144 | + |
| 145 | +--- |
| 146 | + |
| 147 | +## 3. What to Exclude |
| 148 | + |
| 149 | +- **UI Components:** Vue/React components, CSS/SCSS, HTML templates, or anything tied to rendering. |
| 150 | +- **SPA-specific Logic:** Routing, state management (Vuex, Redux, etc.), DOM manipulation, or browser-only APIs unless polyfilled or abstracted. |
| 151 | +- **Build/Deploy Scripts:** Unless they are essential for SDK packaging. |
| 152 | + |
| 153 | +--- |
| 154 | + |
| 155 | +## 4. SDK Target Architecture |
| 156 | + |
| 157 | +- **Monorepo Structure:** Use Nx, Lerna, or Yarn Workspaces. |
| 158 | +- **Packages:** |
| 159 | + - `@mixcore/shared`: All generic utilities and stateless helpers. |
| 160 | + - `@mixcore/base`: Core abstract models, base classes, reusable interfaces. |
| 161 | + - `@mixcore/apis`: API client implementations, endpoints, HTTP logic, auth, error handling. |
| 162 | +- **TypeScript Native:** All new code in TypeScript. Convert existing JavaScript to TypeScript where possible. |
| 163 | +- **ESM & CJS Outputs:** Build for both module formats. |
| 164 | +- **Typed Exports:** All public APIs must export types/interfaces. |
| 165 | +- **Framework Agnostic:** No direct dependency on any frontend framework. If needed, provide adapters in optional peer dependencies. |
| 166 | + |
| 167 | +--- |
| 168 | + |
| 169 | +## 5. Refactoring Requirements |
| 170 | + |
| 171 | +- **Decouple from SPA:** Remove any direct SPA dependencies. If logic is reused, create adapters or hooks that remain in the SPA repo. |
| 172 | +- **Injectable Configuration:** All endpoints, tokens, and environment-specific values must be configured at runtime or via SDK constructors. |
| 173 | +- **Error Handling:** Normalize all API error handling. Provide rich, typed errors. |
| 174 | +- **Documentation:** All public APIs, types, and configuration points must have TSDoc/JSDoc comments. Each package must have a README.md with usage examples. |
| 175 | + |
| 176 | +--- |
| 177 | + |
| 178 | +## 6. Testing & Automation |
| 179 | + |
| 180 | +- **Unit Tests:** For every exported function/class. |
| 181 | +- **Integration Tests:** For API clients, using mock servers where possible. |
| 182 | +- **CI/CD:** Lint, type-check, test, and build each package on every commit. |
| 183 | +- **Versioning:** Per-package semantic versioning (if using monorepo) or global versioning. |
| 184 | + |
| 185 | +--- |
| 186 | + |
| 187 | +## 7. Usage Scenarios |
| 188 | + |
| 189 | +- **Web App:** Import SDK modules for shared logic and API access. |
| 190 | +- **Node.js Backend:** Use API clients/types for backend scripting. |
| 191 | +- **Microfrontends:** Share SDK across independently deployed frontends. |
| 192 | +- **Extensions/Plugins:** Third-party developers can build on top of SDK. |
| 193 | +- **Testing:** Use SDK for E2E and integration tests in other projects. |
| 194 | + |
| 195 | +--- |
| 196 | + |
| 197 | +## 8. Migration Plan |
| 198 | + |
| 199 | +1. **Inventory:** Audit and list all code to move. Map dependencies (internal/external). |
| 200 | +2. **Copy & Adapt:** Move code into new SDK repo, preserving structure. Refactor as required. |
| 201 | +3. **Refactor Imports:** Update all internal imports to use relative paths or packages. |
| 202 | +4. **Test & Validate:** Ensure all moved code passes tests and works independently. |
| 203 | +5. **Document:** Write clear docs for each module/package. |
| 204 | +6. **Deprecate in SPA:** Update SPA to use SDK, deprecate old code. |
| 205 | + |
| 206 | +--- |
| 207 | + |
| 208 | +## 9. Deliverables |
| 209 | + |
| 210 | +- New SDK repository (`mixcore/javascript-sdk`) with: |
| 211 | + - Modular packages: `shared`, `base`, `apis` |
| 212 | + - Type-safe, framework-agnostic, well-documented code |
| 213 | + - Passing tests and CI |
| 214 | + - Migration/usage documentation |
| 215 | + |
| 216 | +--- |
| 217 | + |
| 218 | +## 10. Success Criteria |
| 219 | + |
| 220 | +- All common logic/API code is reusable across Mixcore projects. |
| 221 | +- No SPA or UI dependencies in SDK. |
| 222 | +- All public APIs are typed, documented, and tested. |
| 223 | +- SDK is easy to consume by first- and third-party developers. |
0 commit comments