Estructura de directorio para un sitio web (carpetas js / css / img)


9

Durante años he estado usando la siguiente estructura de directorios para mis sitios web:

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

me pareció perfectamente bien hasta que comencé a usar diferentes componentes de terceros.
Por ejemplo, hoy he descargado un componente de JavaScript selector de fecha y hora que busca sus imágenes en el mismo directorio donde se encuentra su archivo CSS (el archivo CSS contiene URL como "url ('calendar.png')").

Entonces ahora tengo 3 opciones:

1) poner datepicker.css en mi directorio css y poner sus imágenes a lo largo. Realmente no me gusta esta opción porque tendré archivos css e imágenes dentro del directorio css y es extraño. También podría encontrar archivos de diferentes componentes con el mismo nombre, como 2 componentes diferentes, que enlazan a background.png desde sus archivos css. Tendré que arreglar esas colisiones de nombres (renombrando uno de los archivos y editando el archivo correspondiente que contiene el enlace).

2) poner datepicker.css en mi directorio css, poner sus imágenes en el directorio de imágenes y editar datepicker.css para buscar las imágenes en el directorio de imágenes. Esta opción está bien, pero tengo que dedicar un tiempo a editar componentes de terceros para adaptarlos a la estructura de mi sitio. Nuevamente, las colisiones de nombres pueden ocurrir aquí (como se describe en la opción anterior) y tendré que arreglarlas.

3) coloque datepicker.js, datepicker.css y sus imágenes en un directorio separado, digamos / 3rdParty / datepicker / y coloque los archivos según lo previsto por el autor (es decir, / 3rdParty / datepicker / css / datepicker .css, /3rdParty/datepicker/css/something.png, etc.). Ahora empiezo a pensar que esta opción es la más correcta.

Desarrolladores web con experiencia, ¿qué me recomiendan?

Respuestas:


9

Siempre creo un directorio lib para componentes de terceros, realmente no desea cambiar las bibliotecas de terceros a menos que sea estrictamente necesario.

Ve con la tercera opción.


2

En lugar de separar las cosas por tipo de archivo, lo cual me parece arbitrario, organizo los archivos según cómo los desarrolladores los usarán y pensarán en ellos. Divido las cosas en algunas categorías básicas:

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

La opción n. ° 2 tampoco es práctica y peligrosa, ya que tendrá que volver a aplicar todos sus cambios (y, por lo tanto, podría olvidar algunos) cuando actualice sus bibliotecas de terceros. Este es seguramente un gran no no! Las opciones 1 y 3 tienen ventajas y desventajas. Por lo general, voy por una combinación de ambos.

Mi solución es usar la Opción # 1 para mis archivos y la Opción # 3 para bibliotecas de terceros.

Ejemplo:

<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
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.