Puis-je conserver Nuget sur le chemin jQuery 1.9.x / 1.x (au lieu de passer à 2.x)?


86

Comme la plupart des gens, j'utilise le package jQuery Nuget pour rester à jour.

Cependant, avec la sortie de jQuery 2.0, je suis maintenant invité à mettre à niveau jQuery 1.9.1 vers 2.0. À l'heure actuelle, j'ai suffisamment de visiteurs sur mes sites en utilisant des versions `` anciennes '' de navigateurs pour que je préfère m'en tenir à 1.9.x et jQuery Migrate .

Est-il possible de dire à Nuget de s'en tenir à une version particulière (1.9.x) lors de la vérification des mises à jour d'un paquet (jQuery ou autre)?

J'utilise les extensions Visual Studio 2010/2012, mais si je dois utiliser l'interface de ligne de commande dans VS pour contourner ce problème, je le ferai certainement.

Remarque: une chose dans mon esprit est qu'ils ont gâché la mise à jour. Puisque jQuery 1.9.x et 2.0.x / 2.x sont assez différents, il semble qu'ils auraient dû créer un package jQuery 2 (.0.x | .x) à la place.

Bien sûr, les personnes qui souhaitent réellement mettre à jour vers 2.x devront le savoir et changer le paquet qu'elles souhaitent installer. Mais étant donné qu'il contient des changements de rupture, c'est peut-être mieux?


2
Depuis la sortie de 1.10.x, j'ai mis à jour le titre pour le rendre un peu plus clair.
James Skemp

2
Puisqu'ils gardent le package nuget unique, ce serait bien s'ils y ajoutaient simplement les deux versions de jQuery, de sorte que vous ayez les deux branches 1.x et 2.x dans un seul package nuget et que vous puissiez ensuite référencer celle que vous voulez.
John

@John - J'aime ... vraiment cette idée. Ce n'est pas comme si le package mettait à jour les références à la version particulière. La seule chose à laquelle je peux penser, ce sont des projets qui peuvent nécessiter 2.x ou 1.x? Mais, il serait intéressant de savoir si cela fonctionnerait. +1
James Skemp

Réponses:


117

À mon avis, c'est une erreur de la part de l'auteur du package. Une mise à jour qui supprime la prise en charge de plusieurs navigateurs aurait dû être transformée en un package nuget version 2 distinct et annoncée en conséquence, c'est-à-dire avec des clauses de non-responsabilité significatives. La bibliothèque 1.9 n'est pas héritée et recevra d'autres mises à jour dans le futur. J'ai été en contact avec l'auteur du package et j'écrirai plus si je reçois une réponse.

En attendant, vous pouvez contraindre la version de votre package à l'aide de la syntaxe suivante dans votre packages.config:

<package id="jQuery" version="1.9.1" allowedVersions="[1.9.1]" />

Vous trouverez plus d'informations sur les contraintes de version ici:

http://docs.nuget.org/docs/reference/Versioning

Après avoir apporté la modification de configuration, une mise à jour ne doit pas mettre à niveau votre package jQuery vers la version 2.0. Il y a eu des problèmes dans le passé avec le gestionnaire de packages d'interface utilisateur ne respectant pas l' allowedVersionsattribut ( https://nuget.codeplex.com/workitem/1891 ), vous devrez peut-être utiliser la ligne de commande si vous rencontrez ce problème.

Cependant, rien de tout cela ne résout le problème de ce qui se passe lorsque la branche 1.9 est mise à jour car le flux de paquets sera désormais sur la piste 2.0+. Je suppose que vous devrez passer à un nouveau package nuget spécialement écrit pour prendre en charge la version 1.x «héritée», ou copier le script manuellement à chaque fois.

Dans tous les cas, je le mettrai à jour lorsque j'en saurai plus.

Éditer:

L'auteur du paquet a déclaré que les chemins 1.x et 2.x seront pris en charge à l'avenir, c'est-à-dire que le flux du paquet contiendra des versions parallèles au lieu d'être fractionnées. Autant que je puisse voir, la solution est d'utiliser une contrainte de version au niveau de la configuration du package pour empêcher une mise à jour vers la version 2.x, par exemple:

<package id="jQuery" version="1.9.1" allowedVersions="[1.9.1,2)" />

(La spécification des versions min et max dans allowedVersionsdevrait permettre la mise à jour sans risquer de basculer vers la version 2.x. Au fait, la bonne parenthèse semble étrange, mais elle est correcte - cela signifie «inférieur à la version 2».)


Dave, merci d'avoir contacté l'auteur du package. J'ai posté un commentaire sur le billet de blog d'annonce de jQuery 2.0 à propos de ce problème possible; pour une raison quelconque, je pensais que jQuery était maintenu par jQuery, et c'était jQuery Migrate qui était géré en leur nom. J'aurais dû creuser plus loin. +1
James Skemp

@JamesSkemp - Oui, c'est votre question sur le message d'annonce qui m'a amené ici :) Merci d'avoir soulevé la question - j'aurais été surpris moi-même si vous aviez attiré l'attention sur le problème. La situation dans son ensemble est un peu plus compliquée qu'elle ne devrait l'être en réalité, mais j'espère que la réponse mise à jour aidera. Si je trouve un moyen plus simple de gérer la gestion des versions, je ne manquerai pas d'ajouter des informations supplémentaires.
Dave R.

2
L'interface utilisateur NuGet a un bogue qui l'oblige à demander la mise à jour vers jQuery 2.0 même si vous interdisez la mise à jour dans packages.config. Il est ironique que jQuery 2.0 soit sorti si proche de NuGet 2.5. La version 2.5 a un bouton Tout mettre à jour, ce qui serait génial s'il n'y avait pas ce bogue.
Edward Brey

2
J'ai vu qu'il y a maintenant un jquery1paquet sur nuget, qui ne suit que la branche 1.x.
Chris J

1
Seule la mise à jour de la console, et non la mise à jour de l'interface utilisateur, fonctionne pour moi (après l'ajout des versions autorisées). L'interface utilisateur ne permet pas la sélection de projets lors d'une tentative de mise à jour
RockResolve

19

que diriez-vous de spécifier la version?

PM> Package d'installation jQuery -Version 1.9.1

Références: http://nuget.org/packages/jQuery/1.9.1


Question connexe que j'ai posée: stackoverflow.com/q/16126338/11912 En bref, cela fonctionne, mais c'est klunky. Et une mise à jour aveugle le rompt.
James Skemp

En fait, j'ai commencé à utiliser la console beaucoup plus après le snafu de gestion des versions de jQuery (je l'appellerai ainsi). Pas la meilleure solution, mais +1.
James Skemp

+1 car si vous avez déjà mis à niveau vers 2.x par erreur et que vous voulez revenir à 1.9 ET empêcher la mise à niveau vers 2.x, vous devez le rétrograder manuellement comme ceci avant / après l'ajout de la restriction de la réponse approuvée.
Pluc

8

Nuget a maintenant un package jquery1 qui ne suit que la branche 1.x, vous devriez donc pouvoir échanger le package jQuery principal pour celui-ci.


Bonne trouvaille. Bien que la page nécessite un peu de travail pour être plus lisible, j'aime la flexibilité que cela permet d'avoir plusieurs versions de jQuery disponibles.
James Skemp

Bien que cela nous ramène au commentaire de John sur la question; ce serait bien s'il y avait un paquet contenant à la fois 1.x et 2.x, avec la version actuelle de chacun.
James Skemp

2
Mais si vous avez d'autres bibliothèques avec des dépendances jQuery, elles seront toujours là, au mieux vous pourriez l'avoir avec jQuery 2.0. Si vous ne voulez que jQuery 1.x dépendant, cela ne fonctionnera pas et vous devrez regarder la réponse de Dave R
RockResolve

4

J'ai combiné les deux solutions du haut pour @TeYoU

J'ai d'abord installé le package à partir de la console du gestionnaire de packages:

Menu Outils -> Gestionnaire de packages de bibliothèque -> Console du gestionnaire de packages

PM> Install-Package jQuery -Version 1.9.1

Ensuite, j'ai édité le packages.config comme @Dave R. dit:

<package id="jQuery" version="1.9.1" allowedVersions="[1.9.1,2)" />

Ensuite, j'ai mis à jour la version actuelle, actuellement 1.10.2 en utilisant Nuget Manager et cela a fonctionné comme un charme.


1
vous n'avez en fait pas besoin de spécifier la version sur le premier que j'ai trouvé. si vous ajoutez les versions autorisées, puis exécutez une mise à jour, cela vous rétrogradera ...
Martin
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.