🤖 React + Next.js Pipelines: Best Practices for Modern Projects

Tuna — Sun, 07 Sep 2025 18:54:42 +0000

Recently, I contributed to react.dev repo and noticed how their CI/CD pipeline was structured. Clean, automated, and resilient. It made me think: what are the essentials every React/Next.js project should have in its pipeline?

Let’s explore the best practices 🚀.

🎯 The problem with "Basic pipelines"

Many teams set up basic commands

Install dependencies
Build project
Deploy

Sounds fine right? You are missing many critical points.

Bundle size related issues
Broken builds
Inconsistent environments
Slow feedbacks

The list doesn't end here.

The point is: a fragile pipeline leads to fragile releases.

🧬 Essential Steps in a Pipeline

A solid React/Next.js pipeline should go beyond just install, lint, test, build.
Here’s an extended GitHub Actions workflow you can adapt to your projects:

name: CI

on:
  push:
    branches: [ main ]
  pull_request:

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      # Checkout the repo
      - uses: actions/checkout@v3

      # Setup Node.js
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'

      # Clean install dependencies
      - run: npm ci

      # Lint checks (fail fast)
      - run: npm run lint

      # Type checking with TypeScript
      - run: npm run type-check

      # Unit tests with coverage
      - run: npm run test -- --ci --coverage

      # End-to-End tests (optional: Cypress/Playwright)
      - run: npm run e2e

      # Build the Next.js app
      - run: npm run build

      # Run Next.js static analysis
      - run: npm run analyze

      # Check bundle size (with e.g. size-limit)
      - run: npm run size

      # Lint commit messages (Conventional Commits)
      - run: npx commitlint --from=HEAD~1 --to=HEAD

      # Upload build artifacts (optional)
      - uses: actions/upload-artifact@v4
        with:
          name: next-build
          path: .next

👏 Best Practices

Use npm ci over npm install → reproducible, clean installs.
Linting as a first step → fail fast on code style issues.
Unit + integration tests with coverage → reliability guaranteed prior to merging.
Preview deployments (e.g., Vercel, Netlify) → every PR receives a live environment.
Cache dependencies between runs → faster pipelines.
Secrets management → use environment variables safely (no .env leaks!).
Bundle analysis → track performance are monitored in PRs.

🙋 Bonus Steps Worth Adding

Type checking (tsc --noEmit) → prevents runtime bugs.
Playwright / Cypress e2e tests → simulate real user flows.
Accessibility checks (axe-core, Lighthouse CI) → catch issues early.
Storybook build → visual regression testing for UI components..

👋 Conclusion

A bad or poor CI/CD is no more tolerated. Is a powerful tool to leverage the development process.
A solid pipeline should be your safety net
Good pipelines include:

Fast feedback
Error prevention
Consistent environments
Bundle monitoring Of course, pipelines evolve daily, but that's not an excuse to ignore. 👉 The goal isn't perfection, is continuous improvement.

👏 Thank you for reading.
This is my first article.
If you found this useful let me know and share it.
See you around!

🤖 WebOTP API: State of art and UX improvements

Tuna — Wed, 03 Sep 2025 23:34:09 +0000

Phone number verification via OTP via SMS is everyday practice these days: we use it for two-factor authentication, for recovering accounts, and for payment verification. But how secure is it actually? And most importantly — how can we improve user experience without sacrificing security?

🎯 The Problem with Traditional OTPs

Looking back, especially with slower smartphones, OTPs always felt clunky.
You’re browsing a website when the SMS arrives. You switch apps, but your phone lags. You try to copy just the code, but end up selecting the entire message. Frustrated, you decide to type it manually — only to mistype a digit with your thumbs. Meanwhile, the phone keeps freezing and your patience is running out.

The point is clear: a slow, error-prone, and frustrating process.

💿 Support

The WebOTP API remains an experimental extension of the Credential Management API. It’s designed to streamline SMS-based OTP entry by letting browsers auto-fill codes—once the user consents. However, it's not fully production-ready across all browsers.

If it's not fully supported yet, why is it so popular?

Despite its limited browser support, the popularity comes down to a few key factors:

The API dramatically improves the overall UX bypassing the user manual entry.
Low implementation effort for the developers, just a bunch lines of code are needed
Google and W3C are pushing for passwordless and secure login methods
Done is better than perfect

Cool, but who's supporting this feature at the moment?

Chrome
Opera
Safari (Partially)

🧬 How to?

Implementing a proper OTP form is quite easy.

<form action="/verify-otp" method="POST">
  <input type="text"
         inputmode="numeric"
         autocomplete="one-time-code"
         pattern="\d{6}"
         required>
</form>

Here's explained every prop:

type="text" Avoids leading zero numbers error when using type number
inputmode="numeric" Triggers the numeric keyboard on mobile
autocomplete="one-time-code"On mobile suggests OTP directly from SMS
pattern="\d{6}" Ensures only 6 digits code

🙋Works with every message?

Not exactly 🙂

The WebOTP API doesn’t work with every SMS message. It only triggers if the OTP message is in the origin-bound format that browsers expect:

Your code is 123456  

@yourdomain.com #123456

Requirements:

The last line must contain your domain preceded by @.
The OTP must follow a # symbol.
The SMS must be short enough (under ~140 characters).
The page must be served over HTTPS.

👋 Conclusion & Future Outlook

SMS OTP isn't perfect: it's still vulnerable to phishing and SIM swap attacks. For more secure alternatives, the future is in WebAuthn and biometric authentication.

But in the meantime, WebOTP API lets us do this:

Reduce manual input errors.
Dramatically improve UX.
Improve security with a simple change of formatting.

👉 The future may not rely on SMS at all — but in the meantime, we can make it intelligent and safer.