Ci sono due raccomandazioni che farei che coprono la maggior parte delle tue preoccupazioni.
1)
Usa aggiornamento compositore --no-dev per potare le eventuali dipendenze per lo sviluppo solo dal file di blocco. Oppure modifica le tue esigenze in compositore.json per ottenere lo stesso risultato.
In teoria, gli sviluppatori del pacchetto dovrebbero mantenere la versione di produzione più pulita (ad esempio non includendo tutti i test di phpunit). Comunque sì è abbastanza normale avere un sacco di "cruft" nella libreria del fornitore, soprattutto perché il concetto di build è relativamente raro in PHP, quindi "fonti" e "target" sono mescolati.
Demo e readme di sono ancora una parte necessaria della versione 'di distribuzione' di un componente così sarà ancora lì se si specifica no-dev, che è solo per dire "Io non sto sviluppando questo pacchetto, ho lo sto solo consumando ".
Sembra che ci sia una funzione di compositore mancante: un livello superiore a questo, che è davvero un pacchetto minifatto di distribuzione super-pulito.
2)
Tenere la libreria fornitore di sopra della web root.
Ciò impedisce l'esplorazione indesiderata nella libreria del fornitore e rimuove eventuali problemi di sicurezza dei visitatori del sito che esplorano le tue librerie (se questo è ciò a cui eri giustamente preoccupato).
ad es. Uso tipicamente
domain
/api
/etc
/vendor
/www
/js
/css
/images
/index.php
/foo
/bar.php
Dove www è la radice virtuale del web-host. Tutti gli script entry-level sono nella vostra web root come normale e il percorso per il caricamento automatico a ../vendor/autoload.php
O, naturalmente, www/potrebbe essere la cartella principale laravel se si sta utilizzando laravel per il vostro sito web così come api.
api può ospitare un vhost separato per le API di laravel se vengono eseguite separatamente da un sito Web "piatto".
(io continuo altre cartelle di sopra della web root build, docs, src per SASS, JS, ecc Grunt, etc in grado di memorizzare in modo sicuro qualsiasi configurazione, password, chiavi, ecc).
3)
Se non sei ancora felice con il bagaglio, poi come suggerisce l'altro commentatore, che ci si vuole guardare un processo di generazione che pulisce le cose. Questo può diventare complesso e difficile da mantenere!
ad es. è possibile creare una cartella di distribuzione di www (ad esempio l'aggiornamento del compositore, più eventuali compiti di grunt, installazioni di bower, pubblicazione laravel/artisan ecc.), quindi potarla di nuovo (script personalizzati che si dovranno ingegnerizzare) e inserirla in un altro repository che rappresenta un obiettivo di distribuzione appiattito pubblicato. Questo è ciò che distribuiresti sul tuo sito web.
Questo avrebbe dovuto essere automatico o che ci si smettere di fare se dopo circa la terza volta :)
Ma ... si deve chiedere perché altrimenti ci si vuole potare indietro le librerie vendor. Spazio sul disco? Non sono così grandi. Ordine generale? Considera le cartelle come scatole nere e leggi i documenti API. Ad esempio, non guardare :)
Immagino che si possa pulire ogni pacchetto del fornitore di file non necessari prima dell'implementazione, ma non penso che valga davvero la pena. Non proprio sicuro di come influisce la sicurezza, dal momento che quei file non dovrebbero mai essere esposti a nessuno tranne la tua app. – deceze
Sì, posso pulirli da solo, ovviamente, ma l'intero punto di Composer è di automatizzare l'installazione e la configurazione delle dipendenze. Dovrò farlo ogni volta che aggiorno. Mi stavo chiedendo se ci fosse qualche altro modo standard automatizzato per farlo. Ho usato altri sistemi di gestione delle dipendenze in altri linguaggi (come Maven per Java) e normalmente non includono elementi che non sono la distribuzione effettiva che dovrebbe essere fornita in bundle con l'applicazione. Se si desidera accedere ai file demo o ai documenti HTML API, fare riferimento ad essi separatamente, non è necessario includerli nell'applicazione. – jbx
Dovresti ovviamente automatizzare il processo di pulizia come parte dello script di distribuzione. Ma sì, avresti bisogno di aggiornarlo ogni volta che si aggiorna una dipendenza. No, non c'è un vero altro modo. L'autore del pacchetto dovrebbe fare attenzione a non includere il cruft non necessario. – deceze