Passa al contenuto principale
Version: 6.x

Domande frequenti (FAQ)

Perché la mia cartella node_modules utilizza spazio su disco se i pacchetti sono salvati in un archivio globale?

pnpm crea "collegamenti fisici" dall'archivio globale alla cartella node_modules del progetto. I collegamenti fisici puntano allo stesso spazio sul disco dove si trovano i file originali. Quindi, ad esempio, se hai foo nel tuo progetto come dipendenza e occupa 1 Mb di spazio, sembrerà che occupi 1 Mb di spazio nella cartella node_modules del progetto e la stessa quantità di spazio nell'archivio globale. Tuttavia, 1 Mb è lo stesso spazio sul disco indirizzato da due posizioni diverse. Quindi in totale foo occupa 1MB, non 2MB.

Per saperne di più su questo argomento:

Funziona su Windows?

Risposta breve: sì. Risposta lunga: Usare i collegamenti simbolici su Windows è a dir poco problematico, tuttavia, pnpm ha una soluzione alternativa. Per Windows, usiamo le giunzioni.

Ma l'approccio annidato di node_modules è incompatibile con Windows?

Le prime versioni di npm hanno avuto problemi a causa del annidamento di tutti i node_modules (vedi questo ticket. Tuttavia, pnpm non crea cartelle profonde, memorizza tutti i pacchetti pianamente e utilizza collegamenti simbolici per creare la struttura ad albero delle dipendenze.

E i collegamenti simbolici circolari?

Sebbene pnpm utilizzi il collegamento per inserire le dipendenze nella cartella node_modules, collegamenti simbolici circolari vengono evitati perché i pacchetti padre vengono inseriti nella stessa node_modules in cui si trovano le loro dipendenze. Quindi le dipendenze di foo non sono in foo/node_modules, ma foo è in node_modules insieme alle sue dipendenze.

Perché avere collegamenti fisici alla fine? Perché non collegare simbolicamente direttamente all'archivio globale?

Un pacchetto può avere diversi insiemi di dipendenze su una macchina.

Nel progetto A [email protected] può avere una dipendenza risolta in [email protected], ma nel progetto B la stessa dipendenza di foo potrebbe risolversi in [email protected]; quindi, pnpm collega fisicamente [email protected] a ogni progetto in cui viene utilizzato, per creare diversi insiemi di dipendenze per esso.

Il collegamento simbolico diretto all'archivio globale funzionerebbe con il flag --preserve-symlinks di Node, tuttavia, questo approccio ha una pletora dei suoi problemi, quindi abbiamo deciso di attenerci ai collegamenti fisici. Per maggiori dettagli sul perché stata presa questa decisione, vedere questo ticket.

Pnpm funziona su più unità o filesystem?

L'archivio dei pacchetti dovrebbe trovarsi sulla stessa unità e filesystem delle installazioni, altrimenti i pacchetti verranno copiati, non collegati. Ciò è dovuto a una limitazione nel funzionamento del collegamento fisico, in quanto un file su un file system non può indirizzare una posizione in un altro. Vedi il ticket #712 per maggiori dettagli.

pnpm funziona in modo diverso nei 2 casi seguenti:

Il percorso dell'archivio è specificato

Se il percorso dell'archivio è specificato tramite la configurazione dell'archivio, la copia avviene tra l'archivio e tutti i progetti che si trovano su un disco diverso.

Se si esegue pnpm install sul disco A, l'archivio pnpm deve trovarsi sul disco A. Se l'archivio pnpm si trova sul disco B, tutti i pacchetti richiesti verranno copiati direttamente nella posizione del progetto invece di essere collegati. Questo inibisce gravemente i vantaggi di archiviazione e prestazioni di pnpm.

Il percorso dell'archivio NON è specificato

Se il percorso dell'archivio non è impostato, vengono creati più archivi (uno per unità o filesystem).

Se l'installazione viene eseguita sul disco A, l'archivio verrà creato su A in .pnpm-store nella radice del filesystem. Se in seguito l'installazione viene eseguita sul disco B, verrà creato un archivio indipendente su B in .pnpm-store. I progetti manterrebbero ancora i vantaggi di pnpm, ma ogni unità potrebbe avere pacchetti ridondanti.

Cosa fa pnpm store prune? È dannoso?

Il comando pnpm store prune rimuove pacchetti non referenziati.

I pacchetti non referenziati sono pacchetti che non vengono utilizzati da alcun progetto nel sistema. I pacchetti possono diventare non referenziati dopo la maggior parte delle operazioni di installazione, per esempio quando le dipendenze sono ridondanti.

Ad esempio, durante pnpm install, il pacchetto [email protected] viene aggiornato a [email protected]. pnpm manterrà [email protected]1.0.0 nell'archivio, in quanto non rimuove automaticamente i pacchetti. Se il pacchetto [email protected] non viene utilizzato da nessun altro progetto sul sistema, diventa non referenziato. L'esecuzione di pnpm store prune rimuoverà [email protected] dall'archivio.

Eseguire pnpm store prune non è dannoso e non ha effetti collaterali sui tuoi progetti. Se le installazioni future richiederanno pacchetti rimossi, pnpm li scaricherà di nuovo.

È consigliabile eseguire occasionalmente pnpm store prune per ripulire l'archivio, ma non troppo frequentemente. A volte, i pacchetti non referenziati vengono richiesti di nuovo. Questo potrebbe verificarsi quando si cambiano i rami e si installano dipendenze più vecchie, in questo caso pnpm avrebbe bisogno di ri-scaricare tutti i pacchetti rimossi, rallentando brevemente il processo di installazione.

Cosa significa pnpm?

pnpm significa npm performante. @rstacruz ha inventato il nome.

pnpm non funziona con <IL TUO-PROGETTO-QUI>?

Nella maggior parte dei casi significa che una delle dipendenze richiede pacchetti non dichiarati in package.json. È un errore comune causato da una node_modules piatta. Se ciò accade, si tratta di un errore nella dipendenza e dovrebbe essere corretta. Tuttavia, ciò potrebbe richiedere del tempo, quindi pnpm supporta soluzioni alternative per far funzionare i pacchetti difettosi.

Soluzione 1

Nell'esempio seguente, una dipendenza non ha il modulo iterall il proprio elenco di dipendenze.

La soluzione più semplice per risolvere le dipendenze mancanti dei pacchetti difettosi è aggiungere iterall come dipendenza al package.json del nostro progetto.

Puoi farlo, installandolo tramite pnpm add iterall e verrà automaticamente aggiunto al package.json del tuo progetto.

  "dependencies": {
...
"iterall": "^1.2.2",
...
}

Soluzione 2

Una delle soluzioni consiste nell'utilizzare gli hook per aggiungere le dipendenze mancanti al package.json del pacchetto.

Un esempio era Webpack Dashboard che non funzionava con pnpm. Da allora è stato risolto in modo tale che ora funzioni con pnpm.

Era solito generare un errore:

Errore: impossibile trovare il modulo 'babel-traverse'
in /node_modules/[email protected]/node_modules/inspectpack/lib/actions/parse

Il problema era che babel-traverse stato utilizzato in inspectpack che stato utilizzato da webpack-dashboard, ma babel-traverse non è stato specificato nel package.json di inspectpack. Funzionava ancora con npm e yarn perché creano node_modules piatte.

La soluzione era creare un .pnpmfile.cjs con i seguenti contenuti:

module.exports = {
hooks: {
readPackage: (pkg) => {
if (pkg.name === "inspectpack") {
pkg.dependencies['babel-traverse'] = '^6.26.0';
}
return pkg;
}
}
};

Dopo aver creato .pnpmfile.cjs, elimina solo pnpm-lock.yaml - non è necessario eliminare node_modules, poiché gli hook pnpm influiscono solo sulla risoluzione del modulo. Poi, ricostruire le dipendenze e dovrebbe funzionare.

Soluzione 3

Nel caso in cui ci siano troppi problemi, puoi utilizzare l'opzione shamefully-hoist. Questo crea una node_modules piaptta simile a quella creata da npm o yarn, che non è raccomandato in quanto evitare questa struttura è lo scopo principale dell'approccio node_modules di pnpm.

Per usarlo, prova pnpm install --shamefully-hoist.