Struktur Folder yang Rapi untuk Proyek Frontend

Tidak ada satu struktur folder yang benar untuk semua proyek. Struktur yang baik membuat orang dapat menebak lokasi file, membatasi hubungan antarmodule, dan memudahkan proses build atau deployment. Mulailah sederhana, lalu pecah folder ketika ada kebutuhan nyata.

Struktur minimum untuk situs statis

website/
├─ index.html
├─ about.html
├─ articles/
│  ├─ semantic-html.html
│  └─ css-grid.html
├─ assets/
│  ├─ css/
│  │  └─ style.css
│  ├─ js/
│  │  ├─ app.js
│  │  └─ theme.js
│  └─ images/
│     └─ logo.svg
├─ robots.txt
├─ sitemap.xml
└─ README.md

Halaman HTML berada di root atau folder berdasarkan jenisnya. Aset yang dipakai lintas halaman masuk assets. File yang harus tersedia dari root URL, seperti robots dan sitemap, tetap berada di root deployment.

Pilih nama yang stabil untuk file dan URL

Gunakan huruf kecil, tanda hubung, dan nama deskriptif: css-grid-untuk-pemula.html. Hindari spasi, variasi huruf besar-kecil, dan nama seperti final-baru-fix-2.html. Hosting berbasis Linux biasanya membedakan Logo.svg dan logo.svg.

Nama slug adalah bagian dari URL publik. Mengubahnya setelah halaman terindeks membutuhkan redirect; pada hosting statis murni, kemampuan redirect bergantung pada platform. Karena itu pilih nama berdasarkan topik, bukan tanggal atau status sementara.

Pahami path dari lokasi dokumen

<!-- index.html berada di root -->
<link rel="stylesheet" href="assets/css/style.css">

<!-- articles/semantic-html.html naik satu folder -->
<link rel="stylesheet" href="../assets/css/style.css">

<!-- URL absolut dari root domain -->
<link rel="stylesheet" href="/assets/css/style.css">

Path absolut root dapat bermasalah jika situs dipublikasikan di subpath seperti /nama-repo/. Path relatif lebih portabel untuk situs statis tanpa build, sedangkan proyek dengan bundler sebaiknya mengatur base URL melalui konfigurasi.

Pecah JavaScript berdasarkan tanggung jawab

Satu app.js masih wajar untuk interaksi kecil. Ketika file memuat theme, search, modal, data artikel, dan animasi yang tidak berkaitan, pisahkan module berdasarkan fitur.

assets/js/
├─ app.js
├─ core/
│  ├─ dom.js
│  └─ storage.js
├─ features/
│  ├─ search.js
│  ├─ theme.js
│  └─ mobile-menu.js
└─ data/
   └─ articles.js

Jangan membuat folder utils sebagai tempat semua fungsi yang tidak diketahui lokasinya. Nama berdasarkan kemampuan, misalnya format-date.js atau safe-storage.js, memberi batas yang lebih jelas.

Bedakan aset source dan aset publik

Pada proyek tanpa build, file di assets langsung dikirim ke browser. Pada proyek dengan build tool, source dapat berada di src dan output di dist. Folder output biasanya tidak diedit manual.

project/
├─ src/
│  ├─ main.js
│  ├─ styles/
│  └─ components/
├─ public/
│  ├─ favicon.svg
│  └─ robots.txt
├─ dist/          # hasil build
├─ package.json
└─ vite.config.js

Perilaku folder public berbeda antar-tool. Baca dokumentasi tool yang digunakan dan jangan mengasumsikan semua file akan diproses atau diberi hash.

Kelompokkan berdasarkan fitur ketika aplikasi berkembang

Untuk aplikasi dengan banyak halaman dan state, struktur per jenis file dapat membuat satu fitur tersebar jauh. Struktur berbasis fitur menempatkan kode yang berubah bersama di lokasi berdekatan.

src/
├─ app/
│  ├─ router.js
│  └─ bootstrap.js
├─ features/
│  ├─ articles/
│  │  ├─ article-card.js
│  │  ├─ article-filter.js
│  │  └─ article-api.js
│  └─ theme/
│     ├─ theme-toggle.js
│     └─ theme-storage.js
└─ shared/
   ├─ ui/
   └─ utilities/

Folder shared hanya berisi bagian yang benar-benar digunakan beberapa fitur. Jangan memindahkan kode ke shared hanya karena kemungkinan akan digunakan nanti.

Simpan data dan konten pada tempat yang jelas

Metadata artikel dapat berada di file data terstruktur, sementara isi utama tetap dirender sebagai HTML agar mudah ditemukan crawler dan tetap terbaca tanpa JavaScript. Jika data yang sama ditulis di banyak tempat, pertimbangkan generator statis agar satu sumber menghasilkan halaman, kartu, dan sitemap.

Namun generator menambah proses build. Untuk 12 halaman yang jarang berubah, HTML statis plus script audit mungkin lebih mudah dipelihara daripada memperkenalkan framework besar.

Jaga konfigurasi dan rahasia

# Boleh masuk repository sebagai contoh
.env.example

# Jangan masuk repository
.env
.env.local
*.pem
*.key
node_modules/
dist/
coverage/

Semua nilai yang dikirim ke JavaScript browser dapat dilihat pengguna. Environment variable pada proses build bukan otomatis rahasia jika nilainya dimasukkan ke bundle. Kunci API yang membutuhkan kerahasiaan harus digunakan melalui backend yang mengontrol akses.

Gunakan README sebagai peta proyek

README tidak perlu panjang, tetapi harus menjawab cara menjalankan, struktur penting, perintah test/build, target deployment, dan keputusan khusus. Contoh:

# NgodingSantai

## Menjalankan lokal
npx serve .

## Struktur
- `articles/`: artikel statis yang dapat diindeks
- `assets/js/`: interaksi progresif
- `scripts/`: audit sebelum deployment

## Pemeriksaan
powershell -File scripts/browser-audit.ps1 -Mode all-pages

Tanda struktur perlu diubah

• Satu file sering menimbulkan conflict karena memuat fitur tidak terkait.
• Developer sulit menemukan pemilik style atau event.
• Path relatif berulang dan sering salah.
• Kode fitur harus mengimpor detail internal banyak fitur lain.
• Output build tercampur dengan source dan sering diedit manual.
• File bernama helpers.js atau misc.css terus membesar tanpa batas.

Refactor satu batas sekaligus. Pindahkan file, perbaiki import/path, jalankan test, lalu commit. Hindari memindahkan seluruh proyek sekaligus bersamaan dengan perubahan fitur.

Checklist struktur yang sehat

1. Orang baru dapat menemukan entry point dan halaman utama.
2. Nama file konsisten serta aman untuk hosting case-sensitive.
3. Source dan output build tidak tercampur.
4. Rahasia dan dependency hasil instalasi diabaikan Git.
5. Konten utama tetap tersedia pada HTML hasil deployment.
6. README menjelaskan perintah lokal dan audit.
7. Struktur cukup sederhana untuk ukuran proyek saat ini.

Referensi resmi

• MDN: Dealing with files
• MDN: Publishing your website
• Vite: Static Asset Handling
• Git: gitignore documentation