Il core di Discourse sta passando a pnpm per la gestione dei pacchetti JS

Sviluppatore
1

Stiamo passando il gestore di pacchetti JS di Discourse core da ‘yarn classic’ a pnpm. Questo porterà significativi miglioramenti alla velocità di installazione e ai requisiti di archiviazione.

Produzione

Se utilizzi hosting gestito o un’installazione standard, non devi fare nulla. La modifica verrà applicata automaticamente al tuo prossimo aggiornamento.

Se hai un ambiente di produzione personalizzato, dovrai cambiare tutti i comandi yarn ... in pnpm ...

Sviluppo

Dopo aver scaricato l’ultima versione di Discourse core, potresti vedere un errore come questo all’avvio del server:

pnpm non è installato

oppure, se esegui un comando come yarn install, vedrai

errore discourse@: Il motore "yarn" è incompatibile con questo modulo. Versione prevista "please-use-pnpm". Ottenuta "..."

Per risolvere questo problema, dovresti:

  1. eseguire npm install -g pnpm

  2. eseguire pnpm install

  3. sostituire tutti gli utilizzi di yarn ... nel tuo ambiente di sviluppo con pnpm ...

Plugin / Temi

Abbiamo cambiato i nostri plugin/temi ufficiali per utilizzare pnpm per le loro dipendenze di linting.

Per la CLI discourse_theme, dovrai aggiornare la tua versione locale eseguendo gem update discourse_theme.

Tornare a yarn

Se hai bisogno di tornare a una versione di Discourse basata su yarn (ad esempio, sviluppando sul ramo stabile), dovrai eliminare manualmente tutte le directory node_modules di core:

rm -rf node_modules app/assets/javascripts/*/node_modules
24 Mi Piace
2

Posso segnalare un’esperienza impeccabile e fluida sullo sviluppo, funzionante al primo tentativo, grazie mille! :rocket:

7 Mi Piace
3

Se è self-hosted. Dovremo fare qualcosa se non utilizziamo componenti e plugin personalizzati?

Ad esempio, alcuni plugin e componenti non sono ufficiali.

3 Mi Piace
4

Supponendo che tu stia utilizzando la nostra installazione standard, non è necessario fare nulla. Non sono richieste modifiche a plugin o temi.

5 Mi Piace
5

Dovremmo cambiare questa versione prevista in, forse:

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

:smiley:

6 Mi Piace
6

Sto contribuendo a un altro progetto FOSS dove sono stato recentemente introdotto per la prima volta a PNPM. La transizione è stata un gioco da ragazzi, fluida, efficace e un vero piacere.

Ho scritto appunti molto brevi nella documentazione di quel progetto su Cos’è PNPM e come usarlo. Sebbene i piccoli dettagli siano diversi per ogni progetto, spero che ciò che è presente possa fornire una rapida introduzione a chiunque qui, che come me non avesse idea prima che venisse fatto un annuncio.

5 Mi Piace
7

Ottima risorsa, grazie @TonyG

Vale la pena notare, tuttavia, che nessuna delle “note di configurazione” lì è richiesta per Discourse. Non sono sicuro del perché ne abbiano bisogno… forse perché è un’applicazione basata su Windows?

Inoltre, la loro nota su “In un progetto esistente, elimina semplicemente la cartella ‘node_modules’” viene gestita automaticamente in Discourse da questo script :sunglasses:

Quindi per noi, dovrebbe davvero essere semplice come:

npm install -g pnpm
pnpm install
1 Mi Piace
8

Una domanda qui, David:

Come eseguire il linting localmente?

cioè cosa sostituisce, ad esempio: yarn prettier --write plugins/discourse-events

Ho provato a eseguire

pnpm pprettier --write plugins/discourse-events

ma genera un errore:

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

9

Penso che tu abbia troppe p lì?

Quindi vuoi:

pnpm prettier --write plugins/discourse-events

pprettier è uno strumento per eseguire prettier in parallelo, ma immagino che non supporti l’esecuzione su una singola directory in quel modo.

3 Mi Piace
10

Grazie per il tuo contributo alla documentazione FOSS @david :lol_: Sembra che la pagina sia orientata verso Windows e che le informazioni lì potrebbero essere conoscenze richieste per l’uso di pnpm. Modificherò e chiarirò che nessuna delle due cose è vera per quell’utility.

Per essere chiari, le informazioni su come funziona pnpm sono lì solo per la comodità dell’utente/sviluppatore, inclusi coloro che qui potrebbero voler comprendere questo nuovo strumento che sostituisce uno strumento significativo e di uso frequente nel nostro kit.

Per gli sviluppatori di Discourse, tali informazioni spiegano dove si trovano le cose e come modificare le posizioni predefinite. Questo ha lo scopo di rispondere a una domanda come “se tutte le mie node_modules sono ora in un’unica posizione, dove sono?” Nel container di Discourse, voi sviluppatori potreste non volere i pacchetti nella posizione predefinita. Se, per qualsiasi motivo, uno sviluppatore di plugin fa riferimento diretto alla cartella node_modules e trova collegamenti a un’altra posizione anziché file, le informazioni in quella pagina spiegano in modo conciso come viene determinata tale posizione.

Tanto per cercare di essere brevi. :facepalm: :lolsob:

Comunque, buona mossa verso pnpm, e grazie.

2 Mi Piace
11

Sì, pprettier non era appropriato, grazie.

Ho risolto anche il mio problema definitivo.

Apparentemente è necessario eseguire pnpm install nella directory del plugin prima di poter eseguire i controlli di linting (anche dalla directory di discourse).

2 Mi Piace
12

Hmm interessante :thinking:

Con il nostro scheletro di plugin standard, ogni plugin ha il proprio file package.json con le sue dipendenze di linting. E per ora, lo scheletro utilizza ancora yarn.

Quindi, per eseguire il linting di un plugin specifico, dovresti entrare nella directory del plugin ed eseguire

yarn install
yarn prettier --write

L’utilizzo della configurazione di linting di core sui plugin può funzionare a volte. Ma se la versione/configurazione diverge, può diventare doloroso perché la versione di eslint/prettier in core non corrisponderà alla versione in esecuzione nel CI del tuo plugin.

1 Mi Piace
13

Prenderemmo in considerazione anche l’uso di pnpm dalla directory dei plugin?

Credo che stia ancora usando il package.json locale, vero?

3 Mi Piace
14

Sì, lo faremo sicuramente! Stiamo solo lasciando che la polvere si posi sul cambiamento principale prima di iniziare quell’avventura

(curiosità: CDCK mantiene quasi 600 repository di temi/plugin che dovranno tutti essere aggiornati :sweat_smile:)

2 Mi Piace
15

Certamente, nessun problema!

1 Mi Piace
16

Questo sembra aver funzionato correttamente, ma sono stato confuso da un avviso che sembra indicare che questo debba essere fatto manualmente e non automaticamente per i siti con installazione standard:

avviso aggiornamento
avviso aggiornamento1124×370 15.7 KB

2 Mi Piace
18

Grazie @Architect. Queste PR sopprimeranno i messaggi di aggiornamento:

6 Mi Piace
20

Ho riscontrato un problema durante l’aggiornamento tramite lo strumento web: la pagina di aggiornamento ha indicato che l’aggiornamento è fallito, con l’errore Expected version "please-use-pnpm", ma quando ho successivamente visitato di nuovo la pagina Versioni, sembrava che l’aggiornamento fosse riuscito:

Screenshot 2024-09-07 at 09.27.00
Screenshot 2024-09-07 at 09.27.002090×618 51.4 KB

…tuttavia, nessuna delle pagine di amministrazione funziona ora:

Screenshot 2024-09-07 at 09.31.55
Screenshot 2024-09-07 at 09.31.55696×638 14.8 KB

Aggiornamento:
Ho eseguito una ricostruzione dalla riga di comando e questo ha risolto il problema.

3 Mi Piace
21

Grazie per la segnalazione @alxndr.

Ho appena pubblicato questa correzione che dovrebbe impedire che ciò accada ad altri.

4 Mi Piace
22

Forse è il nostro ambiente Communiteq, ma a dire il vero non vedo miglioramenti significativi della velocità durante l’installazione? La nostra installazione di test stabile si installa addirittura 23 secondi più velocemente di quella che ha superato i test.

1 Mi Piace