Discourse core passe à pnpm pour la gestion des packages JS

[david (David Taylor)]

Nous remplaçons le gestionnaire de paquets JS de Discourse core de ‘yarn classic’ par pnpm. Cela apportera des améliorations significatives en termes de vitesse d’installation et d’exigences de stockage.

Production

Si vous utilisez un hébergement géré ou une installation standard, vous n’avez rien à faire. Le changement sera appliqué automatiquement lors de votre prochaine mise à jour.

Si vous avez un environnement de production personnalisé, vous devrez remplacer toutes les commandes yarn ... par pnpm ....

Développement

Après avoir récupéré la dernière version de Discourse core, vous pourriez voir une erreur comme celle-ci au démarrage du serveur :

pnpm n'est pas installé

ou, si vous exécutez une commande comme yarn install, vous verrez

error discourse@: Le moteur "yarn" est incompatible avec ce module. Version attendue "please-use-pnpm". Obtenu "..."

Pour résoudre ce problème, vous devriez :

1. exécuter npm install -g pnpm

2. exécuter pnpm install

3. remplacer toutes les utilisations de yarn ... dans votre environnement de développement par pnpm ...

Plugins / Thèmes

Nous avons fait passer nos plugins/thèmes officiels à l’utilisation de pnpm pour leurs dépendances de linting.

Pour le discourse_theme CLI, vous devrez mettre à jour votre version locale en exécutant gem update discourse_theme.

Revenir à yarn

Si vous avez besoin de revenir à une version de Discourse basée sur yarn (par exemple, pour développer sur la branche stable), vous devrez supprimer manuellement tous les répertoires node_modules du core :

rm -rf node_modules app/assets/javascripts/*/node_modules

[merefield (Robert)]

Je peux signaler une expérience sans faille et fluide sur dev, qui fonctionne du premier coup, merci beaucoup !

[Heliosurge (Dan DeMontmorency)]

Si vous êtes auto-hébergé. Devrons-nous faire quelque chose si nous n’utilisons pas de composants et plugins personnalisés ?

Par exemple, certains plugins et composants ne sont pas officiels.

[david (David Taylor)]

En supposant que vous utilisez notre installation standard, vous n’avez rien à faire. Aucune modification n’est requise pour les plugins ou les thèmes.

[supermathie (Michael Brown)]

@david

Version attendue « please-use-pnpm ».

Devrions-nous changer cette version attendue en, par exemple :

please-use-pnpm-see-https://meta.discourse.org/t/324521

[TonyG]

Je contribue à un autre projet FOSS où j’ai récemment découvert PNPM pour la première fois. La transition a été une évidence, fluide, efficace et un vrai plaisir.

J’ai rédigé des notes très brèves dans la documentation de ce projet sur ce qu’est PNPM et comment l’utiliser. Bien que les moindres détails diffèrent pour chaque projet, j’espère que ce qui est là pourra fournir une introduction rapide à toute personne ici qui, comme moi, n’avait aucune idée avant qu’une annonce ne soit faite.

PNPM Package Manager

[david (David Taylor)]

Bonne ressource, merci @TonyG

Il convient de noter cependant que aucune des « notes de configuration » n’est requise pour Discourse. Je ne sais pas pourquoi ils en ont besoin… peut-être parce que c’est une application basée sur Windows ?

De plus, leur note concernant « Dans un projet existant, supprimez simplement le dossier ‘node_modules’ » est gérée automatiquement dans Discourse par ce script

Donc, pour nous, cela devrait vraiment être aussi simple que :

npm install -g pnpm
pnpm install

[merefield (Robert)]

Une question ici, David :

Comment exécuter le linting localement ?

c’est-à-dire par quoi remplacer, par exemple : yarn prettier --write plugins/discourse-events

J’ai essayé d’exécuter

pnpm pprettier --write plugins/discourse-events

mais cela génère une erreur :

Error: File not found with singular glob: /Users/blah/dev/disc/discourse/plugins/discourse-events (if this was purposeful, use allowEmpty option)

[david (David Taylor)]

@merefield

npnpm pprettier

Je pense que vous avez trop de p là ?

Donc vous voulez :

pnpm prettier --write plugins/discourse-events

pprettier est un outil pour exécuter prettier en parallèle, mais je suppose qu’il ne prend pas en charge l’exécution sur un seul répertoire comme celui-ci.

[TonyG]

@david

Il est intéressant de noter, cependant, qu’aucune des « notes de configuration » n’est requise pour Discourse. Je ne suis pas sûr pourquoi ils en ont besoin…

Merci pour votre contribution à la documentation FOSS @david Il semble que la page soit orientée vers Windows, et que les informations qu’elle contient puissent être des connaissances requises pour utiliser pnpm. Je vais modifier et clarifier qu’il n’en est rien pour cet utilitaire.

Pour être clair, les informations sur le fonctionnement de pnpm sont là uniquement pour le confort de l’utilisateur/développeur, y compris ceux qui aimeraient comprendre ce nouvel outil qui remplace un outil important et souvent utilisé dans notre boîte à outils.

Pour les développeurs Discourse, ces informations expliquent où se trouvent les choses et comment modifier les emplacements par défaut. Ceci est destiné à répondre à une question comme « si tous mes node_modules sont maintenant dans un seul endroit, où sont-ils ? » Dans le conteneur Discourse, vous, les développeurs, pourriez ne pas vouloir que les paquets soient à l’emplacement par défaut. Si, pour une raison quelconque, un développeur de plugin référence directement le dossier node_modules et trouve des liens vers un autre emplacement plutôt que des fichiers, les informations sur cette page expliquent de manière concise comment cet emplacement est déterminé.

Voilà pour avoir essayé d’être bref.

Quoi qu’il en soit, bonne initiative pour pnpm, et merci.

[merefield (Robert)]

Oui, pprettier n’était pas approprié, merci.

J’ai aussi résolu mon problème ultime.

Il faut apparemment exécuter pnpm install dans le répertoire du plugin avant de pouvoir exécuter les vérifications de linting (même depuis le répertoire discourse).

[david (David Taylor)]

Hmm intéressant

Avec notre squelette de plugin standard, chaque plugin a son propre fichier package.json avec ses dépendances de linting. Et pour l’instant, le squelette utilise toujours yarn.

Donc, pour linter un plugin spécifique, vous iriez dans le répertoire du plugin et exécuteriez

yarn install
yarn prettier --write

L’utilisation de la configuration de linting du cœur sur les plugins peut parfois fonctionner. Mais si la version/configuration diverge, cela peut devenir douloureux car la version d’eslint/prettier dans le cœur ne correspondra pas à la version exécutée dans la CI de votre plugin.

[merefield (Robert)]

Devrions-nous envisager d’utiliser pnpm à partir du répertoire des plugins également ?

Je crois qu’il utilise toujours le package.json local, n’est-ce pas ?

[david (David Taylor)]

@merefield

Envisagerions-nous également d’utiliser pnpm à partir du répertoire des plugins ?

Oui, absolument ! Laissons la poussière retomber sur le changement principal avant de nous lancer dans cette aventure

(fait amusant : CDCK maintient près de 600 dépôts de thèmes/plugins qui devront tous être mis à jour )

[merefield (Robert)]

Bien sûr, aucun problème !

[Architect]

@david

Si vous utilisez l’hébergement géré ou une installation standard, alors vous n’avez rien à faire. Le changement sera appliqué automatiquement lors de votre prochaine mise à jour.

Cela semble avoir fonctionné correctement, mais j’ai été confus par un avis qui semble indiquer que cela doit être fait manuellement et n’est pas automatique pour les sites d’installation standard :

[david (David Taylor)]

Merci @Architect. Ces PR supprimeront les messages de mise à niveau :

• UX: Suppress pnpm upgrade notifications in build logs by davidtaylorhq · Pull Request #240 · discourse/docker_manager · GitHub

• Suppress pnpm upgrade notices in logs by davidtaylorhq · Pull Request #866 · discourse/discourse_docker · GitHub

[alxndr (Alexander)]

J’ai rencontré un problème lors de la mise à niveau via l’outil web — la page de mise à niveau indiquait que la mise à niveau avait échoué, avec l’erreur Expected version "please-use-pnpm", mais lorsque j’ai ensuite revisité la page Versions, il semblait que la mise à niveau avait réussi :

…cependant, aucune des pages d’administration ne fonctionne maintenant :

Mise à jour :
J’ai effectué une reconstruction en ligne de commande et cela a résolu le problème.

[david (David Taylor)]

Merci d’avoir signalé, @alxndr.

Je viens de pousser cette correction qui devrait empêcher que cela n’arrive à d’autres.

[RGJ (Richard - Communiteq)]

@david

améliorations significatives de la vitesse d’installation et des exigences de stockage.

C’est peut-être notre environnement Communiteq, mais pour être honnête, je ne constate aucune amélioration significative de la vitesse lors de l’installation ? Notre installation de test stable s’installe même 23 secondes plus rapidement que celle qui a passé les tests.