Automasi linting Next.js penting karena folder pages dan app di Next.js bisa cepat tumbuh dan menghasilkan inkonsistensi stylistik, error runtime yang bisa dicegah, serta PR yang sulit ditinjau. Dengan linting otomatis, Anda memastikan standar kode dipatuhi sebelum build dan deploy, sehingga reviewer bisa fokus pada logika bisnis.

Menyiapkan GitHub Actions untuk linting dan tes

Pipeline yang menyertakan lint, unit test, dan type-check memberi lapisan validasi sebelum kode dikirim ke environment berikutnya. Pastikan file konfigurasi linting (misalnya .eslintrc.js) dan pengaturan jest/tsc sudah cocok dengan struktur Next.js.

Contoh file workflow

name: CI + Release Candidate

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

jobs:
  lint-test-release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'pnpm'
      - name: Install dependencies
        run: pnpm install --frozen-lockfile
      - name: Lint Source
        run: pnpm lint
      - name: Run Tests & Type Check
        run: pnpm test && pnpm tsc --noEmit
      - name: Create Release Candidate Tag
        if: github.event_name == 'push'
        run: |
          VERSION=$(node -p "require('./package.json').version")
          git tag -f rc-${VERSION}
          git push origin rc-${VERSION} --force
      - name: Draft Release (Release Candidate)
        uses: actions/create-release@v1
        with:
          tag_name: rc-${{ steps.version.outputs.value }}
          release_name: "Release Candidate ${{ steps.version.outputs.value }}"
          draft: true
          prerelease: true

Contoh di atas menunjukkan linting, pengujian, dan pembuatan tag release candidate. Gunakan pnpm atau manajer paket lain sesuai proyek Anda. Bagian release candidate mengandalkan versi dari package.json; sesuaikan dengan cara Anda mengatur versioning (misalnya dengan semantic-release jika ingin otomatis lebih lanjut).

Tips caching dan akselerasi pipeline

Caching node_modules atau cache toolchain lainnya menghemat waktu hingga 60% pada build berulang. GitHub Actions menyediakan pengaturan cache di setup-node, tetapi Anda juga bisa menambah actions/cache untuk direktori seperti ~/.pnpm-store atau .next jika build preview menggunakan Next.js Server Components.

  • Gunakan ~/.pnpm-store untuk cache pnpm atau ~/.npm untuk npm biasa.
  • Cache hasil tsc incremental dengan tsconfig yang mengaktifkan incremental dan tsBuildInfoFile.
  • Untuk lint, pertimbangkan cache ESLint agar linting incremental lebih cepat.

Menyambungkan ke release flow dan preview deployment

Setelah linting dan tes lulus, langkah selanjutnya adalah memastikan bahwa artifact siap untuk ditinjau atau di-deploy. Dua pendekatan umum adalah:

  • Tag otomatis dan draft release: workflow di atas membuat tag RC. Gunakan action seperti softprops/action-gh-release untuk membuat draft release yang bisa ditinjau sebelum publikasi final.
  • Deployment preview: gunakan integrasi Vercel atau Netlify yang otomatis membuat preview setiap branch/PR. Pastikan workflow melampirkan status checks (lint, test) pada PR agar deployment preview hanya terjadi jika semua checks lulus.

Untuk mencatat preview deployment di PR, update job terakhir di workflow untuk mengirim komentar dengan link preview menggunakan API Vercel atau output dari action deployment. Ini memastikan reviewer tahu bahwa build sudah berjalan.

Catatan troubleshooting dan metrik DX

Masalah umum:

  • Lint error tiba-tiba: periksa konfigurasi .eslintrc dan versi plugin. Gunakan pnpm lint --max-warnings=0 untuk memaksa perbaikan sebelum merge.
  • Tag RC tertimpa: gunakan strategi versioning yang deterministik, atau jalankan release hanya pada branch protected.
  • Cache invalid: tambahkan kunci cache berdasarkan package-lock.json atau pnpm-lock.yaml untuk memastikan cache ter-refresh saat dependency berubah.

Metrik Developer Experience (DX) yang bisa diukur:

  • Rata-rata waktu pipeline lint+test selesai (target < 5 menit untuk PR kecil).
  • Frekuensi PR gagal karena linting atau type error yang ditemukan terlalu lambat (tujuannya menurun).
  • Persentase release candidate yang tidak memerlukan hotfix setelah QA, menandakan kualitas otomatisasi lint/test.

Dengan menggabungkan linting otomatis, tes, dan release candidate dalam satu workflow GitHub Actions, Anda memastikan bahwa setiap perubahan Next.js melewati proses validasi yang konsisten sebelum mencapai production atau preview deployment.