Estrutura de diretório para um site (pastas js / css / img)


9

Durante anos, tenho usado a seguinte estrutura de diretórios para meus sites:

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

pareceu perfeitamente bom para mim até que comecei a usar diferentes componentes de terceiros.
Por exemplo, hoje eu baixei um componente javascript do selecionador de data e hora que procura suas imagens no mesmo diretório em que seu arquivo css está localizado (o arquivo css contém URLs como "url ('calendar.png')").

Então agora eu tenho 3 opções:

1) coloque datepicker.css no meu diretório css e coloque suas imagens. Eu realmente não gosto dessa opção porque terei arquivos css e de imagem dentro do diretório css e é estranho. Também posso encontrar arquivos de diferentes componentes com o mesmo nome, como 2 componentes diferentes, que apontam para background.png a partir de seus arquivos css. Vou ter que corrigir essas colisões de nomes (renomeando um dos arquivos e editando o arquivo correspondente que contém o link).

2) coloque datepicker.css no meu diretório css, coloque suas imagens no diretório images e edite datepicker.css para procurar as imagens no diretório images. Essa opção está ok, mas tenho que gastar algum tempo para editar componentes de terceiros para ajustá-los à estrutura do meu site. Novamente, colisões de nomes podem ocorrer aqui (como descrito na opção anterior) e terei que corrigi-las.

3) coloque datepicker.js, datepicker.css e suas imagens em um diretório separado, digamos / 3rdParty / datepicker / e coloque os arquivos conforme pretendido pelo autor (por exemplo, / 3rdParty / datepicker / css / datepicker .css, /3rdParty/datepicker/css/something.png, etc.). Agora começo a pensar que esta opção é a mais correta.

Desenvolvedores web experientes, o que você recomenda?

Respostas:


9

Eu sempre crio um diretório lib para componentes de terceiros; você realmente não deseja alterar as bibliotecas de terceiros, a menos que seja estritamente necessário.

Vá com a terceira opção.


2

Em vez de separar as coisas por tipo de arquivo, o que me parece arbitrário, eu organizo os arquivos pela maneira como os desenvolvedores os usarão e pensarão sobre eles. Eu divido as coisas em algumas categorias 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

A opção 2 também não é prática e perigosa, pois você terá que reaplicar todas as suas alterações (e, portanto, pode esquecer algumas) ao atualizar suas bibliotecas de terceiros. Este é certamente um grande não, não! As opções 1 e 3 têm vantagens e desvantagens. Então, eu costumo escolher uma combinação de ambos.

Minha solução é usar a opção 1 para meus arquivos e usar a opção 3 para bibliotecas de terceiros.

Exemplo:

<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
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.