user-client and admin-client are on different major versions of react-query, zustand, and mui-icons
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 48/100
- Tipo de issue
- Refactorización
- Claridad
- Bastante claro
- Estado de actividad
- Tranquilo
- Stack tecnológico
- react, typescript
- Área
- developer-experience, frontend
Línea de trabajo
Start by comparing the dependency declarations and lockfile entries for user-client and admin-client; the issue does not name their manifest paths. First, assess the @mui/icons-material v5-to-v6 bump in admin-client, then inspect state and data-fetching usage before attempting the other upgrades. Done means the chosen package versions are aligned across clients and the affected client builds and tests pass.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Background
While setting up locally I noticed user-client and admin-client each carry their own node_modules folders (177 MB and 58 MB) while backend, common, and integrations do not.
The cause is that the two clients depend on different major versions of a few shared packages:
| Package | user-client | admin-client |
|---|---|---|
@tanstack/react-query |
^5.56.2 |
^4.10.1 |
zustand |
^4.5.5 |
^5.0.0 |
@mui/icons-material |
^6.0.2 |
^5.8.3 |
Yarn (with the node-modules linker declared in .yarnrc.yml) can only hoist one version of a given package to root. When workspaces disagree on the major version, one wins the root spot and the other gets a local copy in its own node_modules.
Nothing is broken today. Each workspace's imports resolve to the correct version via node's module resolution, and the two clients never share objects at runtime.
Problem
The two clients already share a substantial base: React 18, @mui/material v6.1.5, @emotion/react / @emotion/styled, react-hook-form v7, react-router-dom v6, immer v10. The three drifted packages sit directly on top of this shared foundation. Aligning them would give three concrete benefits:
- Maintenance surface will keep growing. React Query v4 is essentially in maintenance mode. Security patches will taper off, adding to the same package-vulnerability churn flagged in #872.
- Blocks shared React code in
common. Because the underlying stack is already aligned, any shared React component, hook, or state helper could be extracted intocommonfor reuse across both frontends. The current drift on these three specific packages blocks that. - API knowledge overhead. Anyone maintaining both frontends has to remember two API generations per library. React Query v4 → v5 in particular has meaningfully different syntax (object-syntax hooks,
placeholderDatareplacingkeepPreviousData, changed filter callbacks).
Proposed approach
Rather than a big-bang alignment project, do the migrations opportunistically as each area is touched. Ordered from lowest effort:
- Bump
@mui/icons-materialin admin-client from v5 to v6. Trivial (icons are SVG components, near-zero API surface). Bonus: admin-client is already on@mui/materialv6.1.5, so the current v5 icons combo is arguably an inconsistency worth fixing anyway. - Bump
zustandin user-client from v4 to v5 next time someone touches user-client's state layer. Largely backward compatible. - Bump
@tanstack/react-queryin admin-client from v4 to v5 next time someone touches admin-client's data-fetching layer. Non-trivial — everyuseQuery/useMutationcall needs review.
Alternatively, if the team prefers to knock all three out as one small tech-debt task, that also works.
- Lenguaje dominante
- TypeScript
- Estrellas
- 4
- Forks
- 0
- Merge medio
- 14 h 50 min
- PR fusionados (30 d)
- 5
Preparar el entorno
- Incluye un Dockerfile o un archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de Garvan-Data-Science-Platform/ctrl
-
Dificultad 1/5 1-3 horas Aptitud para principiantes 82/100
-
admin-client backend bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
-
backend bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Garvan-Data-Science-Platform/ctrl#970 · 1 comentario ·
-
backend bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
-
backend bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Todos los issues de Garvan-Data-Science-Platform/ctrl
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 67/100
agilepathway/label-checker#739 · 4 comentarios ·
Los mantenedores suelen responder en 1 día
-
Wrong key location at startupAbierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 68/100
CopilotKit/OpenBot#800 ·
Los mantenedores suelen responder en 1 día
-
Endpoint links in the tag operations list are below the 24px target sizePosiblemente ocupada @AdzerKI la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 79/100
ehmpathy/rhachet-roles-bhuild#471 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 73/100
Los mantenedores suelen responder en 1 día