Saya sudah mempublikasikan sebuah game web.
Di komputer saya, semuanya berjalan normal. Kode yang sudah diperbaiki ada di GitHub. Proses deployment juga sukses.
Tapi di beberapa HP, game itu tetap rusak.
Di Analytics, saya menemukan error:
SyntaxError: Unexpected token '<'
Saya sedang bekerja dengan JavaScript. Jadi kenapa tiba-tiba tanda “<” yang dianggap bermasalah?
Ini terjadi saat saya mengembangkan ORA Quest. Hal paling berguna yang saya pelajari bukan satu baris kode ajaib, melainkan memahami apa yang sering sebenarnya dimaksud oleh error ini.
- Bisa jadi “<” bukan masalah sebenarnya
- Bug paling menyebalkan sering tidak rusak untuk semua orang
- 5 hal yang sekarang akan saya cek lebih dulu
- GitHub benar belum tentu production juga benar
- Jangan cuma menghilangkan error — buat error berikutnya lebih mudah dipahami
- Solo development sering lebih banyak memahami kenyataan daripada menulis kode
Bisa jadi “<” bukan masalah sebenarnya
Awalnya saya mencari kesalahan sintaks JavaScript. Ada karakter aneh? JSON rusak? Koma hilang?
Tapi ketika muncul Unexpected token '<', ada satu hal yang layak dicek lebih dulu: apakah browser meminta JavaScript atau JSON, tetapi server malah mengirim HTML?
Misalnya browser meminta game.js. Seharusnya responsnya JavaScript. Tetapi server ternyata mengirim halaman error yang dimulai dengan <!DOCTYPE html>.
Browser mencoba membacanya sebagai JavaScript, bertemu < pertama, lalu gagal.
Jadi tanda itu belum tentu pelakunya. Bisa jadi browser menerima jenis konten yang salah.
Bug paling menyebalkan sering tidak rusak untuk semua orang
Itulah yang membuat masalah ini sulit.
Di PC jalan. Di beberapa HP juga jalan. Tetapi di HP lain atau browser di dalam aplikasi media sosial, gagal.
Kita jadi mudah masuk ke pola ini:
ubah kode → deploy → buka di PC sendiri → jalan → anggap selesai.
Dulu saya juga melakukan pengecekan seperti itu.
Padahal kalau masalahnya terkait cache, browser, aset lama, atau jalur request tertentu, komputer developer sendiri bisa memberikan rasa aman palsu.
5 hal yang sekarang akan saya cek lebih dulu
- Buka langsung URL file JS atau JSON yang gagal.
- Pastikan responsnya benar-benar JavaScript atau JSON.
- Cek apakah yang kembali justru halaman 404, login, WordPress, atau HTML lain.
- Pastikan server production benar-benar menyajikan file yang diharapkan dari GitHub.
- Uji di perangkat atau browser lain tanpa bergantung pada cache yang sama.
Poin pertama sangat penting.
Daripada terus mengubah kode karena “kelihatannya error JavaScript”, lebih baik tanya dulu:
Sebenarnya URL ini mengembalikan apa?
Pertanyaan sederhana itu bisa menghemat banyak perbaikan yang salah sasaran.
GitHub benar belum tentu production juga benar
Ini juga pelajaran yang saya dapat dengan cara yang cukup menyakitkan.
Kode yang benar bisa sudah ada di GitHub, tetapi pengguna tetap menerima sesuatu yang berbeda.
Di tengahnya ada proses deployment, hosting, WordPress, cache server atau CDN, cache browser, dan browser bawaan aplikasi.
Cukup satu lapisan mengirim versi lama atau respons yang tidak diharapkan, lalu muncul situasi: “Tapi ini kan sudah saya perbaiki.”
Karena itu definisi “sudah diperbaiki” saya berubah.
Fix belum selesai saat commit sudah benar. Fix selesai saat URL production benar-benar bekerja dalam kondisi yang mirip dengan pengguna nyata.
Jangan cuma menghilangkan error — buat error berikutnya lebih mudah dipahami
Dulu tujuan saya sederhana: hilangkan error secepat mungkin.
Sekarang saya juga mencoba meninggalkan informasi yang cukup jika error itu muncul lagi.
File mana yang gagal? URL apa yang diminta? Lingkungannya apa? Build mana yang sedang berjalan?
Dengan informasi itu, lain kali pertanyaannya bukan lagi “bug misterius ini balik lagi”, tetapi “apakah penyebabnya sama seperti sebelumnya?”.
Tidak terlihat keren, tetapi bagi solo developer yang mengelola layanan sendiri, perbaikan seperti ini kadang lebih berharga daripada satu fitur baru.
Solo development sering lebih banyak memahami kenyataan daripada menulis kode
Sebelum membuat game web, saya membayangkan pengembangan game sebagai membuat karakter, menulis cerita, dan memprogram sistem.
Kenyataannya, banyak waktu habis untuk pertanyaan seperti: kenapa cuma perangkat ini yang gagal? Kenapa JavaScript kemarin masih muncul? Kenapa URL JSON malah mengembalikan HTML?
Setiap kali satu masalah berhasil saya pahami, jangkauan hal yang bisa saya bangun berikutnya sedikit bertambah.
Pelajaran terbesar dari Unexpected token '<' bagi saya adalah:
kode yang kita tulis dan file yang benar-benar diterima pengguna tidak selalu sama.
Kalau Anda sedang menghadapi error ini, sebelum menulis ulang JavaScript, buka langsung URL JS atau JSON yang gagal. Kalau yang terlihat justru HTML, Anda sudah menemukan petunjuk besar.
Saya mempelajari semua ini sambil membangun ORA Quest. Kalau penasaran debugging sebanyak ini akhirnya menjadi apa, Anda bisa mencoba demo ORA Quest secara gratis.
コメント