長年、私は自分のウェブサイトに次のディレクトリ構造を使用してきました。
<root>
->js
->jquery.js
->tooltip.js
->someplugin.js
->css
->styles.css
->someplugin.css
->images
-> all website images...
別のサードパーティコンポーネントを使用し始めるまで、私にはまったく問題ないようでした。
たとえば、今日、cssファイルがある同じディレクトリで画像を検索するdatetime picker javascriptコンポーネントをダウンロードしました(cssファイルには「url( 'calendar.png')」のようなURLが含まれます) 。
だから今、私は3つのオプションがあります:
1) datepicker.cssをcssディレクトリに配置し、その画像を配置します。私はcssディレクトリ内にcssと画像ファイルの両方を持っているので、このオプションが本当に好きではありません。それは奇妙です。また、cssファイルからbackground.pngにリンクする2つの異なるコンポーネントなど、同じ名前の異なるコンポーネントのファイルに出会うこともあります。これらの名前の衝突を修正する必要があります(いずれかのファイルの名前を変更し、リンクを含む対応するファイルを編集します)。
2) datepicker.cssをcssディレクトリに置き、その画像をimagesディレクトリに入れ、datepicker.cssを編集してimagesディレクトリで画像を探します。このオプションは大丈夫ですが、サードパーティのコンポーネントを編集してサイト構造に合わせるために、ある程度の時間を費やす必要があります。繰り返しますが、ここで名前の衝突が発生する可能性があり(前のオプションで説明)、それらを修正する必要があります。
) datepicker.js、datepicker.cssおよびその画像を別のディレクトリに配置します。たとえば、/ 3rdParty/datepicker /とし、作成者が意図したとおりにファイルを配置します(例:/ 3rdParty/datepicker/css/datepicker.css、/ 3rdParty/datepicker/css/something.pngなど)。今、私はこのオプションが最も正しいと考え始めました。
経験豊富なウェブ開発者、あなたは何をお勧めしますか?
私は常にサードパーティのコンポーネント用にlibディレクトリを作成します。厳密に必要でない限り、サードパーティのライブラリを変更したくありません。
3番目のオプションを選択します。
ファイルの種類によって物事を分けるのではなく、私にとってはarbitrary意的であると思うので、開発者がファイルをどのように使用して考えるかによってファイルを整理します。いくつかの基本的なカテゴリに分けます:
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)
オプション#2は、サードパーティライブラリをアップグレードするときにすべての変更を再適用する必要があるため(したがって、一部を忘れる可能性があるため)、実用的でも危険でもありません。これは確かに大きな違いです!オプション#1と#3にはそれぞれ利点と欠点があります。だから、私は通常両方の組み合わせに行きます。
私の解決策は、ファイルにオプション#1を使用し、サードパーティのライブラリにオプション#3を使用することです。
例:
<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