Structure de répertoire pour un site Web (dossiers js / css / img)


9

Depuis des années, j'utilise la structure de répertoires suivante pour mes sites Web:

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

cela m'a semblé parfaitement bien jusqu'à ce que je commence à utiliser différents composants tiers.
Par exemple, aujourd'hui, j'ai téléchargé un composant javascript datetime picker qui recherche ses images dans le même répertoire où se trouve son fichier css (le fichier css contient des URL comme "url ('calendar.png')").

Alors maintenant, j'ai 3 options:

1) mettez datepicker.css dans mon répertoire css et placez ses images. Je n'aime pas vraiment cette option car j'aurai des fichiers css et image dans le répertoire css et c'est bizarre. Je peux également rencontrer des fichiers de différents composants portant le même nom, tels que 2 composants différents, qui sont liés à background.png à partir de leurs fichiers CSS. Je devrai corriger ces collisions de noms (en renommant l'un des fichiers et en modifiant le fichier correspondant qui contient le lien).

2) mettez datepicker.css dans mon répertoire css, placez ses images dans le répertoire images et éditez datepicker.css pour rechercher les images dans le répertoire images. Cette option est correcte mais je dois passer un peu de temps à modifier les composants tiers pour les adapter à la structure de mon site. Encore une fois, des collisions de noms peuvent se produire ici (comme décrit dans l'option précédente) et je vais devoir les corriger.

3) mettez datepicker.js, datepicker.css et ses images dans un répertoire séparé, disons / 3rdParty / datepicker / et placez les fichiers comme prévu par l'auteur (par exemple, / 3rdParty / datepicker / css / datepicker .css, /3rdParty/datepicker/css/something.png, etc.). Maintenant, je commence à penser que cette option est la plus correcte.

Développeurs Web expérimentés, que recommandez-vous?

Réponses:


9

Je crée toujours un répertoire lib pour les composants tiers, vous ne voulez vraiment pas changer les bibliothèques tierces sauf si cela est strictement nécessaire.

Allez avec la 3e option.


2

Au lieu de séparer les choses par type de fichier, ce qui me semble arbitraire, j'organise les fichiers selon la façon dont les développeurs les utiliseront et y penseront. Je divise les choses en quelques catégories de 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'option n ° 2 n'est pas pratique et dangereuse car vous devrez réappliquer toutes vos modifications (et donc en oublier certaines) lorsque vous mettez à niveau vos bibliothèques tierces. C'est sûrement un gros non non! Les options 1 et 3 présentent chacune des avantages et des inconvénients. Je préfère donc généralement une combinaison des deux.

Ma solution consiste à utiliser l'option n ° 1 pour mes fichiers et à utiliser l'option n ° 3 pour les bibliothèques tierces.

Exemple:

<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
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.