Struttura delle directory per un sito Web (cartelle js / css / img)


9

Per anni ho usato la seguente struttura di directory per i miei siti Web:

<root>
  ->js
    ->jquery.js
    ->tooltip.js
    ->someplugin.js
  ->css
    ->styles.css
    ->someplugin.css
  ->images
    -> all website images...

mi è sembrato perfettamente perfetto finché non ho iniziato a utilizzare diversi componenti di terze parti.
Ad esempio, oggi ho scaricato un componente javascript del selettore datetime che cerca le sue immagini nella stessa directory in cui si trova il suo file css (il file css contiene URL come "url ('calendar.png')").

Quindi ora ho 3 opzioni:

1) metti datepicker.css nella mia directory css e metti le sue immagini. Questa opzione non mi piace molto perché avrò sia i file css che i file immagine nella directory css ed è strano. Inoltre potrei incontrare file da diversi componenti con lo stesso nome, come 2 componenti diversi, che si collegano a background.png dai loro file CSS. Dovrò correggere quelle collisioni di nomi (rinominando uno dei file e modificando il file corrispondente che contiene il collegamento).

2) metti datepicker.css nella mia directory css, metti le sue immagini nella directory images e modifica datepicker.css per cercare le immagini nella directory images. Questa opzione è ok ma devo dedicare un po 'di tempo alla modifica dei componenti di terze parti per adattarli alla struttura del mio sito. Ancora una volta, qui possono verificarsi collisioni di nomi (come descritto nell'opzione precedente) e dovrò risolverli.

3) metti datepicker.js, datepicker.css e le sue immagini in una directory separata, diciamo / 3rdParty / datepicker / e posiziona i file come previsto dall'autore (ad esempio, / 3rdParty / datepicker / css / datepicker .css, /3rdParty/datepicker/css/something.png, ecc.). Ora inizio a pensare che questa opzione sia la più corretta.

Sviluppatori web esperti, cosa mi consigliate?

Risposte:


9

Creo sempre una directory lib per componenti di terze parti, davvero non vuoi cambiare librerie di terze parti a meno che non sia strettamente necessario.

Vai con la 3a opzione.


2

Invece di separare le cose per tipo di file, il che mi sembra arbitrario, organizzo i file in base a come gli sviluppatori useranno e penseranno a loro. Suddivido le cose in alcune categorie di base:

myapp/
  ui/ # or "www"
    lib/ # third-party
      jquery/
      sugarjs/
      backbone/
      underscore/
    app/ # application logic
      main.js
      router.js
      views.js
      models.js
    style/ # all presentation
      main.css
      buttons.css
      icons/
        add.svg
        log.png
      img/
        logo.png
        signup.png
    components/ # standalone bundles of html/css/js, if necessary
  server/ # or "api" (all server-side logic)

0

L'opzione n. 2 non è anche pratica e pericolosa in quanto dovrai riapplicare tutte le modifiche (e quindi potresti dimenticartene alcune) quando aggiorni le tue librerie di terze parti. Questo è sicuramente un grande no no! Le opzioni n. 1 e n. 3 presentano vantaggi e svantaggi. Quindi di solito vado per una combinazione di entrambi.

La mia soluzione è utilizzare l'opzione n. 1 per i miei file e utilizzare l'opzione n. 3 per le librerie di terze parti.

Esempio:

<root>
  -> js
    -> jquery.js
    -> main.js
  -> css
    -> reset.css
    -> style.css
  -> img
    -> img1.jpg
    -> img2.jpg
  -> lib
    -> someplugin1
      -> original folder/file structure of this plugin
    -> someplugin2
      -> original folder/file structure of this plugin
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.