post-image

Standarisasi Project Next.js Kamu

23 Oktober 2022

Tutorial

Read in English
Share on Twitter

Table of contents

Disclaimer

Di artikel ini, says akan fokus untuk melakukan standarisasi pada project Next.js (Typescript). Teman-teman pembaca bisa menyesuaikan dengan source code project masing-masing atau berdasarkan kebutuhan ya.

Introduction

Berdasarkan pengalaman saya di dunia programming, Javascript (dan Typescript) adalah bahasa pemrograman yang paling “liar” yang pernah saya pelajari. Saya dengan mudahnya bisa menggunakan code convention versi mana saja sesuka hati saya setiap kali membuat project menggunakan Javascript ini.

Ketika saya membuat personal project, sepertinya tidak menjadi masalah besar karena saya koding hanya untuk diri sendiri dan hanya saya saja yang mengerti kodingan sendiri, hahaha. Tetapi bayangkan kalau harus bekerja dalam tim yang terdiri dari bebrapa orang dan tiap orang juga berpikiran sama bahwa mereka punya code style masing-masing dan koding seenaknya? BOOOM, hancur sudah isi kodingannya.

Nah ini adalah salah satu contoh alasan kenapa kita butuh standarisasi untuk source code kita sebagai programmer. Ini sebenarnya adalah masalah umum yang dialami banyak programmer di luar sana, apalagi dalam tim. Tapi setidaknya ini juga bisa jadi pengingat bagi kita semua ya untuk tetap membuat kodingan yang rapi dan enak dibaca baik untuk diri sendiri atau orang lain

Mengapa Kita Butuh Standarisasi untuk Source Code kita?

Nah sebelum lebih jauh, seperti biasa kita harus mulai dengan “why”. Kenapa sih sampai harus pakai standarisasi segala?

Setiap Anggota Tim Punya “Code Style” Mereka Masing-Masing

Nah seperti yang saya sebutkan di bagian pendahuluan, ketika saya membuat personal project, mungkin tidak terlalu menjadi masalah besar apabila tidak ada standarisasi yang jelas karena hanya saya sendiri yang membuatnya.

Berbeda jika saat bekerja dalam tim, apalagi sekarang ketika saya bekerja sebagai full-time frontend engineer. Setiap orang punya gaya kodingannya sendiri. Tentu ini bisa membuat bingung sendiri ketika mendapat suatu task lalu harus membaca kodingan milik anggota tim lain dan memahaminya terlebih dahulu.

Tidak hanya saya ternyata, ketika orang lain membaca kodingan saya pun sering mereka merasa bingung karena gaya kodingannya berbeda. Inilah mengapa perlu dibuat semacam code convention, supaya kode yang dibuat tetap konsisten walaupun dalam sebuah tim yang orangnya ada banyak.

Meningkatkan Maintainability dan Readability

Saya pernah bekerja di sebuah software house yang sistem kerjanya berbasiskan project. Tugas engineer bisa dibilang selesai ketika project telah di-deliver kepada client.

Saya saat itu masih sebagai junior frontend engineer dan tentunya sebagai fresh graduate juga saya seringkali membuat kodingan “bar bar”, hahaha. Dalam pikiran saya saat itu, saya hanya perlu menyelesaikan request dari user dan deliver ketika semuanya selesai. Sungguh pengalaman tidak terlupakan.

Semua berubah ketika saya pindah ke sebuah perusahaan yang tergolong sebagai in house company. Yang mana mereka memiliki produk tersendiri yang dikembangkan dalam perusahaan tersebut.

Yang tadinya hanya fokus untuk koding lalu “lempar”, sekarang tidak bisa seperti itu, hahaha. Saya juga harus memikirkan kodingan saya tetap bisa ter-maintain dengan baik dan juga harus readable sehingga memudahkan apabila perlu improvement di masa mendatang.

Caranya sebenarnya cukup simpel, hanya buat dan ikuti code convention yang telah disepakati sehingga kodingannya bisa tetap konsisten walaupun dibuat oleh beberapa orang dalam tim. Kode yang konsisten membuatnya mudah dibaca, nah kalau mudah dibaca dan dimengerti, tentunya akan mudah untuk maintenance.

Tidak Hanya Kodingan, Commit Message juga Perlu Standarisasi

Jika bekerja dalam tim, sangat penting untuk membuat commit message yang mudah dipahami oleh anggota tim lain sebelum push ke Git repository. **Kodingan yang rapi tentunya akan terlihat sia-sia kalau commit message-nya berantakan. ****Ketika terjadi issue dan harus dilakukan tracking, akan kebingungan sendiri karena commit-messange nya berantakan.

Syukurlah sekarang ada Conventional Commit yang bisa membantu developer untuk membuat commit message yang mudah dibaca.

Bagaimana Cara Standarisasi Source Code Project Kita?

Di sini saya akan bahas dari perspektif frontend engineer ya. Dalam hal ini adalah Next.js. Di dunia pemrograman Javascript, ada beberapa tools yang bisa dimanfaatkan untuk membantu kita melakukan standarisasi kodingan.

Hanya untuk memberikan contoh, saya telah menyiapkan sample project Next.js sederhana (Typescript) yang bisa diakses di next-tailwind-polos. Kalian bisa melakukan konfigurasi dan standarisasi kodingan menggunakan contoh project ini. Silahkan di-clone dan jangan lupa untuk install dependencies dengan yarn atau npm install.

Ini yang akan kita lakukan berikutnya.

Di langkah berikutnya saya akan menggunakan yarn, teman-teman pembaca bisa menyesuaikan apabila menggunakan npm. Untuk lebih lengkapnya, silahkan lihat dokumentasi resmi untuk penggunaan tools terkait ya

Konfigurasi Prettier

Nah saya asumsikan kalian sudah clone contoh project yang saya berikan di bagian sebelumnya ya, sehingga di sini sudah mulai fokus untuk penggunaan tools terkait.

Pastikan kalian sudah membuka folder projectnya baik dari VS Code atau terminal kalian, lalu jalankan yarn add --dev --exact prettier. Lalu, buat file dengan nama .prettierrc.json di root folder, atau bisa juga tinggal jalankan echo {}> .prettier.json di terminal kalian.

Nah di dalam .prettierrc.json, kalian bisa isi dengan konfigurasi seperti di bawah ini, atau kalian bisa modifikasi sesuai keinginan dan preferensi kalian. (referensi: Prettier Config Options).

{
  "endOfLine": "lf",
  "semi": true,
  "singleQuote": false,
  "tabWidth": 2,
  "trailingComma": "es5"
}
json

Nah, sekarang kalian hanya perlu jalankan yarn prettier --write [directory scope] untuk melakukan format pada kodingan kalian. Atau jika kalian menggunakan VS Code, kelian bisa set Format on Save di VS Code Settings kalian, tapi pastikan kalian sudah menginstall ekstensi Prettier ini di text editor kalian. Selain itu, bisa juga menggunakan shortcut Shift + Option + F (di macbook) atau Shift + CTRL + F (di windows) untuk memformat file kodingan secara manual.

Konfigurasi Base ESLint Rules

Karena kita menggunakan Next.js, kita akan memakai ESLint for Next.js. Beruntung di Next.js terbaru, ESLint secara default telah terinstall secara default di dalam project ini sejak project diinisiasi. Jadi dalam case ini, kita bisa fokus ke file eslintrc.json yang ada di root folder.

Tapi pastikan juga bahwa lint command sudah ada di dalam file package.json.

"scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start",
    "lint": "next lint"
  }
...
json

Kurang lebih, ini isi konfigurasi ESLint milik saya di file eslintrc.json. Kamu tidak perlu tiru 100% ya. Kembali lagi ke kebutuhan masing-masing.

{
  "env": {
    "node": true
  },
  "extends": [
    "next/core-web-vitals",
    "eslint:recommended",
    "plugin:@typescript-eslint/recommended"
  ],
  "parser": "@typescript-eslint/parser",
  "plugins": ["import", "unused-imports", "@typescript-eslint"],
  "settings": {
    "import/resolver": {
      "node": {
        "extensions": [".js", ".jsx", ".ts", ".tsx"],
        "moduleDirectory": ["node_modules", "src/"]
      }
    }
  },
  "rules": {
    "no-unused-vars": "off",
    "@typescript-eslint/no-unused-vars": "off",
    "@typescript-eslint/explicit-module-boundary-types": "off",
    "@typescript-eslint/no-non-null-assertion": "off",
    "@typescript-eslint/no-inferrable-types": "off",
    "@next/next/no-img-element": "off",
    "unused-imports/no-unused-imports": "error",
    "unused-imports/no-unused-vars": [
      "warn",
      {
        "vars": "all",
        "varsIgnorePattern": "^_",
        "args": "after-used",
        "argsIgnorePattern": "^_"
      }
    ],

    "no-eq-null": "warn",
    "import/order": [
      "warn",
      {
        "groups": [
          ["builtin", "external"],
          "internal",
          "parent",
          ["sibling", "index"],
          "object"
        ],
        "newlines-between": "always",
        "alphabetize": {
          "order": "asc",
          "caseInsensitive": true
        }
      }
    ],
    "complexity": "warn",
    "no-console": ["error"]
  }
}
json

Di sini, saya menggunakan third-party ESLint plugin seperti import, unused-import, dan typescript-eslint.

Setelah proses konfigurasi di sini selesai, kamu bisa jalankan yarn lint untuk mengecek apakah kodingan-mu sudah sesuai dengan rules yang ada atau belum. Kamu juga bisa jalankan yarn lint --fix yang otomatis melakukan fixing di kodinganmu berdasarkan rules yang telah ditentukan. Perlu diingat, bahwa terkadang kita harus melakukan fixing manual terhadap kodingan kita, jangan terlalu mengandalkan fixing otomatis dari fitur ini ya.

Konfigurasi Husky

Ingin menambahkan otomatisasi? Dalam hal ini saya biasa menggunakan Husky untuk secara otomatis mengecek kodingan atau commit message sebelum commit atau push ke Git Repository.

Karena kita menggunakan yarn, kita akan install dengan menjalankan npx husky-init && yarn di terminal. Itu akan secara otomatis men-generate prepare command di dalam package.json dan base pre-commit config.

husky install

Setelah itu, kita akan menginstall https://github.com/okonet/lint-staged untuk men-trigger dan menjalankan linter di tahap git staged files dengan mengeksekusi npx mrm@2 lint-staged. Itu akan otomatis men-generate base command untuk men-trigger pre-commit husky config file. Lalu, kamu bisa hapus atau sesuaikan kembali isi kontennya sesuai preferensimu. Setelahnya, ketika melakukan commit ke Git repository, otomatis akan menjalankan pengecekan linter. Jadi, pastikan kodinganmu sudah sesuai dengan rules dalam linternya ya.

Lint staged install

Seperti yang telah saya sebutkan sebelumnya, tidak hanya kodingan, kita pun perlu standarisasi commit message sebelum melakukan push ke Git Repository. Di sini kita akan memakai Commit Lint dengan menjalankan yarn add --dev @commitlint/config-conventional @commitlint/cli di terminal.

Perlu diingat juga kita perlu membuat file konfigurasi commitlint ini dengan menjalankan perintah seperti di bawah ini di terminal.

echo "module.exports = { extends: ['@commitlint/config-conventional'] };" > commitlint.config.js
bash

Nah setelah itu, kita bisa integrasikan dengan husky dengan menjalankan yarn husky add .husky/commit-msg 'yarn commitlint --edit $1'. Itu akan secara otomatis men-generate file konfigurasi husky yang bernama commit-msg.

commit-msg

Nah sekarang kamu tidak bisa lagi membuat commit message yang “bar bar” hahaha. Saran saya, gunakan ekstensi VS Code Conventional Commit.

commitlint

Ingin menambahkan pengecekan otomatis lagi sebelum push ke Git Repository? Bisa, di sini contohnya saya bisa jalankan npx husky add .husky/pre-push 'yarn lint' untuk men-generate file husky config baru yang men-trigger pengecekan linter sebelum push ke Git Repository.

pre-push

Nah selesai deh. Perlu diingat lagi, kamu tidak perlu meniru 100% metode yang telah saya beritahukan di sini. Kamu bisa juga menyesuaikan kembali konfigurasinya sesuai dengan kebutuhanmu

Closing

Sebenarnya cara ini bukan cara satu-satunya ya. Masih banyak metode atau tools lain yang tidak kalah efektif sebenarnya yang juga bisa membantu kita melakukan standarisasi source code kita. Semoga ini bisa membantu teman-teman ya. Silahkan diskusikan ini di kolom komentar ya.

Back To Articles Page
Home
Projects
Articles
About Me