Mise à jour des librairies JS pour SPIP 3.2-dev
Jquery
Hop,
Mise à jour des librairies JS pour SPIP 3.2-dev
Jquery
Des contre-indications ?
Je suis pour, mais il faut marcher sur des œufs car ça risque de casser pas mal de choses dans prive/javascript et dans des plugins comme crayons (au hasard ^^).
Jquery UI
Des contre-indications ?
Rien à redire de ce côté pour moi, ça permettrait de se débarrasser de pas mal de getscript en cascade qu'on a dans le core et dans des plugins 
zoubis
Bruno Bergot a écrit le 12/01/2017 à 21:01 :
Hop aussi !
Je suis pour, mais il faut marcher sur des œufs car ça risque de casser
pas mal de choses dans prive/javascript et dans des plugins comme
crayons (au hasard ^^).
Justement, pas lui car il charge sa propre version* de jquery (renommée cquery).
* version qui pourrait sans doute gagner à être modernisée. Gilles en avait parlé…
Je confirme, ça casse des trucs. Mais il faudra bien s'y atteler un jour 
Ceci dit le plugin jquery-migrate-3.0.0.js pourrait être ajouté aux scripts chargés, ça rendrait la migration plus douce (il atténue pas mal les problèmes et loge en console les utilisations dépréciées).
MM.
Je viens de tester en local de mettre jQuery 3.1 + jQuery migrate.
J'ai différents "warnings" du plugin migrate (sur les .load, .bind qui doivent être modifiés en .on() particulièrement), mais tout fonctionne.
Il n'y a eu qu'une seule véritable erreur sur les différents plugins que j'ai testé rapidement (agenda, formidable, champs extras, gis, mediathèque, ...). Seul bizarrement un .load() sur le porte plume créait une erreur dans Sizzle ; ce qui veut dire à la fois que le plugin de migration marche bien, mais qu'il n'est pas exempt de cas particuliers qui peuvent couiner.
Suite à ce test, je pense que ça serait bien effectivement de mettre jQuery 3.1 + migrate (avec les logs dans un premier temps), et migrer tranquillement les JS des plugins et de SPIP en fonction des logs en console. Y en a pas 50 non plus, ça devrait aller vite, en tout cas pour ces fonctions .load, .bind, .unbind, .live, etc.
MM.
Jquery UI
Des contre-indications ?
Rien à redire de ce côté pour moi, ça permettrait de se débarrasser de
pas mal de getscript en cascade qu'on a dans le core et dans des plugins
Ok, on a quelques soucis avec l'intégration de jquery UI 1.12 "simplement".
Du coup, on se disait qu'on allait vraiment charger tout le JS / thème d'un coup (et n'avoir que le fichier .js complet), avec une option de configuration pour charger tout le js dans le public également. jQuery UI ayant modifié encore les chemins, explosé core.js en plein de petits fichiers .js , ça devient extrêmement casse pied de gérer les dépendances.
On vient de retrouver une discussion également en septembre :
Mise à jour des librairies JS pour SPIP 3.2-dev
Jquery
Est-ce que ça poserait problème de mettre dans la 3.2 la toute dernière
version de jQuery ? elle enlève le support des IE<9, mais il semble
qu'il n'en reste vraiment plus beaucoup ("Can I use" usage table)
Jquery 3.1 a été intégré dans SPIP 3.2-dev, ainsi actuellement que le plugin de migration vers jQuery 3.
Jquery UI
Dans la foulée, mettre à jour jQuery UI, est autre question : peut on
charger dans l'espace privé *tout* jquery UI par défaut ? c'est ~280ko
minifié quand même, mais il me semble que ça simplifierait l'usage pour
différents plugins ?
JQuery UI est passé en version 1.12 dans SPIP 3.2-dev. Comme on l'expliquait, cela ne s'est pas déroulé comme on avait imaginé au premier abord (conserver les différents petits fichiers de jQuery UI), et on a préféré intégrer directement TOUT jquery-ui.js et le thème CSS associé dans l'espace privé.
De même dans l'espace public, dès qu'un script jQuery-ui est demandé via le pipeline jqueryui_plugins, alors TOUT le jquery-ui.js est dorénavant chargé. Autrement dit le pipeline "jqueryui_plugins" indique plutôt maintenant, s'il a au moins une entrée, s'il faut charger jQuery UI dans le public.
MM.