compositore è auto-descritto come ispirato da npm, quindi perché gestisce le dipendenze secondarie in modo diverso? [chiuso]

Question

compositore è auto-descritto come ispirato da npm, quindi perché gestisce le dipendenze secondarie in modo diverso? [chiuso]

#1 da (2 voti)

2

Come sono sicuro che chiunque lo stia leggendo sa, il comportamento predefinito per npm è di installare sub-dipendenze all'interno delle loro rispettive directory di subdipendenza stesse (in una nuova directory node_modules ). D'altra parte, il comportamento predefinito per il compositore pone semplicemente tutte le dipendenze, incluse le dipendenze secondarie, in una singola directory vendor . Come meglio posso attualmente ipotizzare, questo mi sembra un design scarso, dal momento che potrebbe causare conflitti se due diverse dipendenze dovessero utilizzare due diverse versioni specifiche della stessa sotto-dipendenza.

Ma, naturalmente, penso che si dovrebbe supporre che i progettisti del compositore debbano aver avuto alcune buone ragioni per questa deviazione dal design di npm. Quali potrebbero essere alcuni di questi motivi?

php node.js dependency-management

posta Eva 29.07.2015 - 01:00

fonte

1 risposta

Leggi altre domande sui tag php node.js dependency-management

Come gestire l'ora predefinita quando l'utente sta selezionando le date da filtrare? Come creare un sistema di messaggistica riutilizzabile basato su comandi

score 2 · Accepted Answer

Prima di tutto, non penso che Composer stia tentando troppo di essere una versione PHP di NPM - potrebbero esserci delle somiglianze, ma ci si devono aspettare delle differenze. Potrebbe non essere il modo migliore per comprenderlo pensando allo strumento come NPM, Maven, Rake o altro, ma tradotto in PHP.

In secondo luogo, comprendi che Composer risolve il "problema" dell'autoloading in PHP. Avere due diverse versioni di una determinata libreria nella tua directory vendor/ non è uno stato di cose per cui Composer si sforza di ottenere qui, e forse questa è una buona cosa. Tutto nella tua directory vendor/ è accessibile dal codice di accesso dell'utente tramite lo stesso autoloader. Perché vorresti più di una classe con lo stesso nome di classe pienamente qualificato? Cosa dovrebbe succedere se si fa riferimento a quel nome di classe nel proprio codice - quale si desidera? Non sono sicuro che dovremmo anche volere che PHP sappia cosa fare quando si confrontano con due diversi pezzi di codice ciascuno cercando di interagire con versioni leggermente diverse della stessa dipendenza.

Il compositore sostituisce detto come Pear e Pecl in PHP, ed è stato parzialmente ispirato agli standard PSR-0/4 per il caricamento automatico di PHP. Ti dà tutte le tue dipendenze in un unico posto. Rende le dipendenze parte del tuo progetto, non parte della sua documentazione. Usa il versioning semantico che sta diventando standard nelle librerie PHP per trovare versioni delle tue dipendenze che giocano bene insieme, e se non ce ne sono, ti dice tanto.

Non abbiamo mai avuto uno strumento come questo in PHP, e il cambiamento che ha contribuito a far precipitare è una consapevolezza molto maggiore sulle parti della biblioteca e degli autori del framework su come i loro strumenti funzionano o non funzionano insieme. Molto è essere il duca nella comunità per affrontare queste sfide. Il compositore potrebbe non essere esattamente come NPM, ma la sua gestione della gestione dei pacchetti PHP è ideale per il linguaggio e colma una lacuna che ha reso la distribuzione di una grande applicazione PHP un dolore al collo.