Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v12 #210

Open
JabX opened this issue Jan 7, 2025 · 0 comments · May be fixed by #216
Open

v12 #210

JabX opened this issue Jan 7, 2025 · 0 comments · May be fixed by #216
Labels
Effort: moyen Peut être fait en une semaine Priorité: haute C'est une demande récurrente et (presque) incontournable

Comments

@JabX
Copy link
Member

JabX commented Jan 7, 2025

Montées de version

Il faut passer toutes les versions majeures suivantes, qui sont potentiellement des breaking changes :

  • react 19 (parce qu'ils retirent enfin tous les trucs dépréciés depuis des années)
  • mobx-react 9 (parce que les props ne sont plus observables dans les composants classes)
  • eslint 9 (parce que le format de configuration change)
  • lodash => es-toolkit, pour avoir une alternative moderne
  • numeral => Intl.NumberFormat, qui est une API native du navigateur

Retrait du module legacy et support des composants classes

La montée de version de mobx-react est aussi l'occasion de passer aux décorateurs standards stage-3, qui ne sont pas compatibles avec les anciens. Toutes ces évolutions combinées vont rentre une éventuelle montée de version pour les projets qui utilisent encore des composants classes très difficile, sans compter le temps qu'il faudrait pour mettre à jour le module legacy lui même.

Le plus simple (pour l'instant en tout cas, il n'est pas exclus de revenir sur la décision plus tard, au moins partiellement) sera donc de supprimer le module legacy (AutoForm, @classAutorun et l'ancien routeur à base de ViewStore essentiellement), ainsi que les APIs makeFormNode/makeFormActions pour être cohérent. Si jamais un ancien projet souhaite faire la mise à jour vers la v12 dans le futur, son temps sera bien mieux utilisé à migrer vers des composants fonctions plutôt que de repasser sur tous ses composants classes pour essayer de continuer à les faire fonctionner...

Installation

Inverser toutes les dépendances de Focus aujourd'hui redéclarées en peer dependencies dans les projets (Focus a des peer dependencies et les projets définissent les dépendances donc), avec un outil CLI dans le module tooling pour gérer l'installation et la mise à jour. Cela pourrait aussi être la disparation du méta-module focus4 qui ne devrait plus servir si son boulot actuel est fait avec une CLI.

@JabX JabX added Effort: moyen Peut être fait en une semaine Priorité: moyenne On peut contourner si c'est pas fait mais c'est bof Priorité: haute C'est une demande récurrente et (presque) incontournable and removed Priorité: moyenne On peut contourner si c'est pas fait mais c'est bof labels Jan 7, 2025
@JabX JabX linked a pull request Feb 12, 2025 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Effort: moyen Peut être fait en une semaine Priorité: haute C'est une demande récurrente et (presque) incontournable
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant