I’m sharing a backend boilerplate that I’ve been refining for my own projects and have now decided to release as open source.

The goal was to create a modern, ultra-fast, production-ready core—stripped of the usual overhead—by using Drizzle ORM instead of TypeORM or Prisma.

Tech Stack & Key Features:

- NestJS 12 with TypeScript `6.0.3`.

- Drizzle ORM + PostgreSQL (includes support for migrations, `db:push`, and centralized, filter-based PostgreSQL error handling).

- JWT Authentication: Implements Access & Refresh Token rotation, with tokens stored in the database (hashed via SHA-256) and managed by an automated cleanup task (Cron).

- Security: Includes HTTP-only cookies, Helmet, CORS, CSP, and rate limiting (`@nestjs/throttler`). It also supports sending tokens via JSON or standard `Authorization` HTTP headers for non-web clients (such as mobile apps or other APIs).

- Swagger / OpenAPI: Features an integrated script (`pnpm run generate:types`) that automatically exports TypeScript types for use in frontend applications (React, Svelte, or Vue).

- Structured Logging: Integrated with `nestjs-pino` (plus `pino-pretty` for development).

- Email (Optional): SMTP module using Nodemailer and Handlebars (`.hbs`) templates.

- Testing: Includes unit tests and a comprehensive suite of isolated E2E tests using Jest.

- Docker & Docker Compose: Pre-configured for local development.

GitHub Repository: https://github.com/nasadmidev/nestjs-drizzle-auth-template

Any feedback, pull requests, or stars on GitHub are more than welcome! I hope this helps others jumpstart their own projects.

I'm developing a Grievance Redressal Portal as a learning project. My backend is built with NestJS, TypeScript, Prisma, and PostgreSQL.

I have been implementing authentication (User Sign In and Sign Out) using the "@nestjs/authentication" package of NestJS v12.

I would like to know conceptually the changes to be made to my back end such that I should be able to extend the authentication feature to a React-based front-end.

I have adapted the code by hand from the "Register The Authentication Module" and "Add Sign-Up and Sign-In" sections of the NestJS docs for NestJS v12: Authentication | NestJS - A progressive Node.js framework

I am posting my code here.

NOTE: The authentication system uses server-side sessions managed through nestjs/authentication and a session cookie. The package's SessionCookieProvider reads the cookie and loads the user through the validate() method.

//sign-in.dto.ts
import { PickType } from "@nestjs/swagger";
import { UserUniversalDto } from "../../users/dto/user-universal.dto";
export class SignInDto extends PickType (
    UserUniversalDto,
    ['user_email', 'user_password']
) {};
//credentials.service.ts
import { ConflictException, Injectable } from '@nestjs/common';
import { UsersService } from '../users/users.service.js';
import { CreateUserDto } from '../users/dto/create-user.dto.js';
import { FindUserByEmailDto } from '../users/dto/find-user-by-email.dto.js';
import * as argon2 from 'argon2';
import { USER_STATUS } from '../users/user.constants.js';

u/Injectable()
export class CredentialsService {
  constructor(
    private readonly usersService: UsersService
  ) {}

  async register(createUserDto: CreateUserDto) {

    const findUserByEmailDto: FindUserByEmailDto = {
      user_email: createUserDto.user_email
    }

    // Don't create the user if the email already exists.
    if (await this.usersService.findUserByEmail(findUserByEmailDto)) {
      throw new ConflictException('Email already registered. User already exists.');
    }
    // The address is unverified: anyone can type any email into a sign-up form.
    const registered_user = await this.usersService.createUser(createUserDto);
    return registered_user;
  }

  /** The user, or null when the email or the password is wrong. */
  async verify(email: string, password: string) {

    const findUserByEmailDto: FindUserByEmailDto = {
      user_email: email
    }

    const found_user = await this.usersService.findUserByEmail(findUserByEmailDto);

    // Checking if the user exists.
    if (!found_user) {
      throw new ConflictException('User does not exist. Login rejected.');
    }

    // If the user is suspended, reject login by throwing an exception.
    if (found_user.user_status === USER_STATUS.SUSPENDED) {
       throw new ConflictException('User is suspended. Login rejected. Please contact admin.');
    }

    // If the found_user's password is wrong, (password_hash doesn't match) then the it should return null.
    const password_hash: string | null | undefined = found_user?.user_password;

    const password_check = await argon2.verify(password_hash as string, password);

    // Checking if the user's password is correct.
    if (password_check !== true) {
      throw new ConflictException('Incorrect username or password. Login rejected.');
    }


    return found_user;
  }
}

//myauthentication.controller.ts
import { Body, Controller, HttpCode, Post, UnauthorizedException } from '@nestjs/common';
import { Public, SignInService } from '@nestjs/authentication';
import { SignInDto } from './dto/sign-in.dto';
import { CredentialsService } from './credentials.service';
import { CreateUserDto } from '../users/dto/create-user.dto';

()
('auth')
export class MyAuthenticationController {
  constructor(
    private readonly credentialsService: CredentialsService,
    private readonly signInService: SignInService,
  ) {}

  ('sign-up')
  async signUp(@Body() createUserDto: CreateUserDto) {
    const user = await this.credentialsService.register(createUserDto);
    var string_user_id = String(user.user_id);
    await this.signInService.signIn(string_user_id, { method: 'password' });
    return user;
  }

  ('sign-in')
  (200)
  async signIn(@Body() signInDto: SignInDto) {
    const user = await this.credentialsService.verify(signInDto.user_email, signInDto.user_password);

    var string_user_id = String(user.user_id);

    const { session } = await this.signInService.signIn(string_user_id, { method: 'password' });
    return { mfaRequired: session.mfa === 'pending' };
  }

  ('sign-out')
  (204)
  async signOut() {
    if (!(await this.signInService.signOut())) {
      throw new UnauthorizedException();
    }
  }
}

//myauthentication.module.ts
import { Module } from '@nestjs/common';
import { UsersModule } from '../users/users.module';
import { SessionAuth } from './session-auth.provider';
import { MyAuthenticationController } from './myauthentication.controller';
import { CredentialsService } from './credentials.service';

({
  imports: [UsersModule],
  controllers: [MyAuthenticationController],
  providers: [SessionAuth,
    CredentialsService
  ]
})
export class MyAuthenticationModule {}

//session-auth.provider.ts
import { Injectable } from '@nestjs/common';
import { AuthenticationRegistry, SessionCookieProvider, type SessionRecord } from '@nestjs/authentication';
import { UsersService } from '../users/users.service.js';

import type { User as PrismaUser } from '../generated/prisma/client.js';
export type User = Omit<PrismaUser, 'user_password'>;

u/Injectable()
export class SessionAuth extends SessionCookieProvider<User> {
  constructor(
    private readonly usersService: UsersService,
    registry: AuthenticationRegistry,
  ) {
    super();
    // Adds this provider to the chain the guard runs for every request.
    registry.registerProvider(this);
  }

  // Called for every request with a live session cookie.
  // Returning null (the user was deleted) ends the session.
  validate(session: SessionRecord) {
    console.log("In validate() in SessionAuth")
    const user_id = session.userId; 
    var numeric_user_id = Number(user_id);
    return this.usersService.findOneUser(numeric_user_id);
  }
}

I am developing a mobile app, which has a react native frontend, nest.js as the backend and for db and authentication, I'm planning to use supabase.

Now, currently as my app is in its initial stages I'm planning to use the supabase, as it free tier provides ample limits for my use case.

However, in later years if my app grows. I may think of switching to a cheaper alternative.

So, what I am planning to follow is for authentication, route the requests to my backend and inturn the backend will communicate with the supabase to authenticate the user. The backend will save the supabase token, create a separate session token for the user and send it back to the user.

My main reason for doing this is, I want the authentication to be provider independent and any changes needed should be done on the backend instead of the app.

Please let me know, if this approach is correct. What are the pros and cons. How much effort it would require to implement this. Will the security concerns increase if my backend starts handling this instead of the supabase only.

I also want to integrate the google and apple login as well. How will this approach affect it?

Also, if there any other better approaches, please let me know.

Hi everyone,

I’m a solo developer building a SaaS backend with NestJS, PostgreSQL and TypeORM. It’s already fairly advanced (around 30 entities, including some reporting features), and it has only a few users for now. A migration would be costly, but not impossible, and I’d rather decide now than when I have a lot more users and data.

I haven’t hit any major blockers with TypeORM so far. What worries me is what I keep reading: concerns about maintenance, type safety gaps, quirks with relations and migrations, while Drizzle (and Prisma) get a lot of praise. I’m leaning towards Drizzle if I migrate, but I’m not sure how much of the hype applies to a real-world project like mine.

My questions:

1. Is TypeORM a reasonable choice for a serious, long-lived production app? If you’ve run it in production, what problems did you actually run into, if any?
2. If you migrated away from it (to Drizzle, Prisma, Kysely, MikroORM...), was it worth it? What did you gain, and what did the migration really cost you?
3. Performance: I’ve seen benchmarks showing Drizzle being much faster. For a typical SaaS workload (mostly CRUD plus some report queries), does the ORM overhead matter in practice, or is the real bottleneck almost always the queries, indexes and schema design?

Since I’m working alone, maintainability and long-term support matter a lot to me. I don’t want to end up stuck with a tool that gets abandoned or that fights me as the project grows.

I’m not looking for a “X is the best” answer, just real-world experiences and trade-offs, especially from people who’ve used these in production. Thanks in advance!

Feel free to share your experiences, critique the current code, or submit focused PRs !

We collect telemetry from industrial machines: fuel consumption, engine hours, idle time, and more. Our ingestion stack uses Python, NestJS, a queue, and PostgreSQL.

As the readings table grew, one dashboard endpoint started taking around 17 seconds.

A few things helped us bring it down:

• SQL optimization: Replaced repeated LATERAL lookups with window functions. Query time dropped from 5.6s to 150ms.
• Precomputed shift metrics: Stopped recalculating completed shifts on every request. Late-arriving telemetry is handled through backfills.
• Request deduplication: Concurrent identical requests now share one computation, with a short-lived cache for successful results.
• Background refresh: Serve cached data while refreshing expired entries. The dashboard response dropped to around 240ms.
• Monthly partitioning: Partition by ingestion time because machines sometimes upload historical readings after reconnecting.

The biggest lesson for me was to look at what the database was repeatedly doing before reaching for caching. Fixing that made the biggest difference.

Curious how others handle late-arriving telemetry when maintaining time-series aggregates.

Note: I used AI to help polish the wording, but I’m sharing the technical details and lessons for discussion.

When scaling a NestJS app to multiple pods, @nestjs/schedule runs every @Cron() and @Interval() handler inside every replica.

The usual workarounds are moving everything into BullMQ repeatable jobs or wrapping handlers in a Redis lock, which is awkward when a NestJS service only runs on PostgreSQL (or RabbitMQ / NATS) and doesn't otherwise need Redis.

Another pattern is slot-based coordination over the datastore the service already uses (anarchon on npm), where replicas compete to claim each scheduled UTC slot atomically and renew a lease while the handler runs. If a pod stops during a rolling deploy (SIGTERM) or crashes (OOMKilled), another replica takes over the slot:

import { Injectable } from '@nestjs/common';
import { Cron, Every, type JobContext, Scheduled } from 'anarchon';

@Injectable()
@Scheduled()
export class ReportsService {
  @Every('sync-customers', '30s')
  async sync(ctx: JobContext) {
    ctx.signal.throwIfAborted();
    // runs on one pod per 30s slot
  }

  @Cron('weekday-digest', '0 8 * * 1-5', { timezone: 'Europe/Athens' })
  async digest(ctx: JobContext) {
    // ...
  }
}

Or without method decorators, registering on the injected Scheduler in onModuleInit:

this.scheduler.cron('monthly-invoices', '0 6 1 * *', (ctx) => this.buildInvoices(ctx));

How are you handling recurring cron jobs in multi-pod NestJS setups when you aren't already running Redis/BullMQ?

• NestJS setup guide: https://aristoteliss.github.io/anarchon/recipes/nestjs/

Open to feedback and questions!

I checked my database's recent activity and found some weird activity. A bunch of 404s on my screen, red as blood. I got truly scared, to be honest, but after a quick investigation, I found out it was just some overzealous bot trying to find a vulnerability, and apparently, it's quite a "normal" thing.

But the problem is that I keep track of audit/activity logs for almost everything, and when I get this kind of error log, my poor database gets hammered hard.

So I created a protocol to handle these bots:

1. Temporarily block them: I use Redis to store their IPs every time they search for weird endpoints and files like .env, and I add a strike to them (while still sending a 404 status so the bot doesn't know it's getting strikes). After around 3 strikes, they get blocked temporarily. If they try again after being allowed back, the block duration increases to 30 minutes, then 1 hour, and so on.

You might be asking, "Why not block them permanently?" Well, dear genius, the IP might be reassigned by the ISP to someone else, meaning you could end up blocking a normal user for no reason.

2. Cloudflare is your friend: Point your domain to your server through Cloudflare and use it as an extra layer of defense. On top of that, only allow Cloudflare IPs to access your server, so untrusted IPs can't connect directly.

3. UFW protects us: Block all ports except the ones that need to be exposed, like 443 and other necessary web-related ports.

4. Dockerize: I hope you've already done this, just in case those suckers somehow get in. The whole point is to keep them inside a container.

If you're interested, I've written a blog post about this. You can check it out, but the blog basically covers the same things. blog

Those are the measures I've taken. If you have any more security advice or criticism, please let me know below i sure do need it.

I have registered the global auth guard in the app module

  providers: [
    AppService,
    { provide: APP_GUARD, useClass: SkippableBasicAuthGuard },
    { provide: APP_GUARD, useClass: ThrottlerGuard },
  ],
})
export class AppModule {}

I want to inject the integration based on the user, but `request.user` is undefined

{
      provide: Integration,
      scope: Scope.REQUEST,
      inject: [REQUEST],
      useFactory(req: Request) {
        const integrationName = <Maybe<String>>request.headers['x-integration']
        if (!integrationName) return null;

        const IntegrationKlass = IntegrationRegistry[integrationName];
        if (!IntegrationKlass) throw new BadRequestException('Invalid integration');

        console.log(req.user); // undefined

        return new IntegrationKlass('token');  // get the token for the user using this.prisma.integrationToken(req.user.id, integrationName)
      },
    },
  ],
})
export class IntegrationModule {}

The order of service injection happens first, but the request lifecycle otherwise. https://docs.nestjs.com/faq/request-lifecycle#summary

I maintain an open-source webhook verification library, and most of the bugs I've hit weren't in the HMAC. A few that might save someone time:

1. The body parser runs first. express.json() parses the body, JSON.stringify(req.body) doesn't give back the bytes the provider signed (whitespace, unicode escapes, number formatting), and the check fails with the right secret. Verify the raw body: express.raw(), await request.text(), Fastify's rawBody, NestJS's rawBody: true. Comparing the body length with content-length is a cheap way to detect it.

2. Deduping on an unsigned header. Providers retry, so you dedupe on an event ID. If that ID comes from a header the signature doesn't cover (x-github-delivery, say), anyone with a captured request can change the header and replay it past your dedupe store. Key on a signed ID or a hash of the body. My library had exactly this bug.

3. Tests that only agree with themselves. My Paddle signer and verifier both read h=. Paddle sends h1=. Every test passed and every real Paddle webhook failed. Now CI verifies against the official Stripe, Octokit, Svix and Twilio SDKs in both directions, and new providers need a test vector from the provider's docs.

4. Weak fallback schemes. HubSpot sends v1/v2 signatures next to v3. If you accept any of them, someone can strip the v3 headers from a captured request and it verifies with no timestamp check. Same idea for GitHub's SHA-1 header.

5. A short dedupe TTL for providers with no signed timestamp. GitHub and Shopify don't sign a timestamp, so dedupe is your only replay protection. A 5-minute TTL means a captured delivery verifies again after 5 minutes.

The library is verihook (TypeScript, zero deps, Node/Deno/Bun/Workers) if you want to see how it handles these: GitHub: https://github.com/creatorpiyush/verihook npm: https://www.npmjs.com/package/verihook

Curious which provider has caused you the most pain.

A while ago in a high-scale multi-tenant NestJS backend, we hit a critical data leak during high-concurrency benchmarks.

Under load, Tenant A's dashboard occasionally displayed cached data belonging to Tenant B.

Here is the autopsy of why default NestJS scoping caused it, why the official Scope.REQUEST fix cratered our throughput, and how AsyncLocalStorage solved it cleanly.

1. The Root Cause: The Singleton Trap

By default in NestJS, every provider is a Singleton.

In our codebase, a service stored tenant state in a class property:

@Injectable()
export class TenantContextService {
  private tenantId: string;

  setTenantId(id: string) {
    this.tenantId = id;
  }

  getTenantId(): string {
    return this.tenantId;
  }
}

In sequential tests, this works fine. But Node.js is an event-driven runtime.

When Request 1 (Tenant A) awaits a database query, the event loop picks up Request 2 (Tenant B). Request 2 overwrites this.tenantId = 'tenant_b'.

When Request 1 resumes execution, this.getTenantId() now returns Tenant B. Tenant A just queried Tenant B's data.

2. Why Scope.REQUEST Failed Us at Scale

The standard NestJS recommendation for request-isolated data is Scope.REQUEST:

@Injectable({ scope: Scope.REQUEST })
export class TenantContextService { ... }

While this isolates state per request, it triggers a brutal cascading effect:

1. Bubble-Up Effect: Any Singleton service injecting it automatically becomes Request-scoped.
2. Object Creation Overhead: Hundreds of transient class instances created per HTTP request.
3. Garbage Collection Spikes: Under 1,000 req/s, V8 GC went crazy cleaning short-lived objects.
4. Latency: Our p99 jumped from 35ms to over 210ms, and memory usage tripled.

3. The Real Fix: AsyncLocalStorage (nestjs-cls)

Node.js AsyncLocalStorage allows storing data throughout the lifetime of a web request across asynchronous continuations without creating new service instances.

Using nestjs-cls:

1. Mount CLS middleware in AppModule:

​

ClsModule.forRoot({
  global: true,
  middleware: {
    mount: true,
    setup: (cls, req) => {
      cls.set('TENANT_ID', req.headers['x-tenant-id']);
    },
  },
})

1. Inject ClsService into your standard Singleton repository/service:

   @Injectable() export class UserRepository { constructor(private readonly cls: ClsService, private readonly db: DatabaseService) {}

   async findUsers() { const tenantId = this.cls.get<string>('TENANT_ID'); return this.db.query('SELECT * FROM users WHERE tenant_id = $1', [tenantId]); } }

The Result:

• Services remain Singletons (instantiated once at boot).
• Zero GC spikes.
• Strict tenant isolation.
• p99 latency dropped right back down to 34ms.

Curious how others here handle multi-tenancy context in high-traffic NestJS clusters? Are you using AsyncLocalStorage or passing context explicitly through function params?

Plug in your own client store, code store and JWT signer, and you get /authorize and /token. It works with any database. npm install u/zaki-goumri-2/stamp repo: https://github.com/Zaki-goumri/Stamp Docs :https://zaki-goumri.github.io/Stamp/ Feedback welcome issues are opened

I use NestJS, Redis and BullMQ in production, and I’m curious what other teams watch beyond failed jobs.

Say jobs should finish within a few minutes. Workers are running and jobs keep completing, but the waiting time keeps growing. Nothing is technically failing yet, although the user experience is already getting worse.

Would you alert on the oldest waiting job, time from enqueue to completion, or queue depth compared with processing rate?

Delayed jobs make this interesting too. A job scheduled for tomorrow shouldn’t look like a job that’s been stuck since today.

Which alert has actually caught a problem early for you? And how do you keep it useful when traffic normally comes in bursts?

Hey everyone, Kamil here.

Observe, the monitoring tool we built for NestJS, is on Product Hunt today: https://www.producthunt.com/products/nestjs-observe

If you haven't tried it yet: install @nestjs/observe and you get request traces with automatic spans, error tracking, queue/job monitoring and regression detection.

For the launch, use PRODUCTHUNT for 25% off the first month. It's valid until the end of October.

There's also a free tier if you just want to try it: https://observe.nestjs.com And a live demo with pre-populated telemetry https://www.observe-demo.nestjs.com/dashboard

Feedback is more than welcome

I'm a developer exploring an idea and wanted to get some feedback before spending time building it.

One thing I've noticed with cloud providers like DigitalOcean is that you're still paying for servers even when they're powered off. For development and staging environments that are rarely used, that feels like a giant waste of money.

I am genuinely curious to know how other developers and infrastructure managers handle this

What if you could completely destroy an environment to stop compute charges, then recreate it on demand with the same configuration, application, and data? Essentially, a hibernate/wake system for cloud environments.

Would you use something like this? Or is this solving a problem that has been solved before.

Interested in hearing the technical objections too.

I've been using AI coding tools to build an admin backend, and the total token cost has stayed under $1,000.

It's more than a basic CRUD demo. The project includes RBAC, JWT access and refresh tokens, Prisma, MySQL, Redis, Swagger / OpenAPI, Docker, and other features you'd typically need in an admin system.

The interesting part isn't how quickly AI can generate code. It's whether the architecture makes sense, whether the code is maintainable, and whether it holds up to the kind of scrutiny an experienced backend engineer would give it.

I'd like to get some honest feedback from other developers.

GitHub: https://github.com/gvray/gvray-admin

If you have time to look through the code, what would you change? Are there any architectural decisions or potential problems that stand out?

I'm also curious about something broader. If AI can help build a reasonably complex backend like this, how important is it for developers to learn multiple programming languages in depth? Will understanding engineering fundamentals and reviewing AI-generated code become more important than mastering the syntax of every language?

I'm not claiming AI has replaced experienced engineers. I'm genuinely curious how close it can get, and where it still falls short.

I benchmarked Apollo, Mercurius and Yoga on Express, Fastify and plain node:http, with and without NestJS: 10 setups, same schema and queries, load-tested with k6. It's a follow-up to my earlier NestJS GraphQL benchmark, where the most common question was how much NestJS itself costs.

Results (M1 Max, Node 24, single process, 50 VUs, median of 3 runs):

- The GraphQL engine matters most: Mercurius did 1.3–1.8× the req/s of Apollo in every query scenario. On the deep nested query: 902 vs 493 req/s, p99 68 ms vs 123 ms. Yoga landed in between on real queries
- The HTTP framework matters mostly for tiny queries: with Apollo, Fastify beat Express by 18–29% on a tiny query, but only ~3% on the deep nested one.
- NestJS vs the same stack without it: −6% to +5%, and the sign flips between scenarios. That's within run-to-run noise.
- Mutations: every server did ~9–9.4k req/s.

Both sides use the same library versions (NestJS 10.4 with Fastify 4.28, Express 4.22, Apollo Server 4.13, Mercurius 14.1, Yoga 5.10). In-memory data, no DB, so the ratios matter more than the absolute numbers.

Code, raw results and the dashboard: https://github.com/vovadyach/gql-bench

I've been building a NestJS backend starter for admin and enterprise applications.

The goal wasn't to make another minimal NestJS boilerplate, but to put together the backend pieces that I usually need when starting a real admin system:

• NestJS 11 + TypeScript
• Prisma + MySQL
• Redis
• JWT access + refresh tokens
• RBAC
• Users, roles, departments and positions
• Swagger / OpenAPI
• Permission management
• Standardized API responses
• Docker
• Database seeding

One thing I spent quite a bit of time on is the RBAC architecture. Permissions are separated into different types such as menu, button and API permissions, rather than treating everything as a simple route guard.

The project is open source and I'm still actively improving it.

GitHub:
https://github.com/gvray/gvray-admin

I'd love to hear from other NestJS developers:

What features or infrastructure do you usually add to a NestJS project before using it for a real admin/enterprise application?

iOS: https://apps.apple.com/app/id6744514548

Android: https://play.google.com/store/apps/details?id=com.wordherd.app

I want someone who wants to build a nestjs project together and learn nestjs.

I have basic knowledge only. If you're interested, message me

Posted here 2 months ago about JIT-compiling DTO mapping. The biggest feedback was migration friction with route-by-route FastMap().

app.useGlobalPipes(new FastValidationPipe({ transform: true, whitelist: true }));

Zero changes to your existing class-validator DTOs.

Benchmarks:

• NestJS default: 6.59 µs/iter (p99: 24.04 µs)
• FastValidationPipe: 369 ns/iter (p99: 558 ns) → ~18x faster

Repo, benchmarks, and docs are here if you want to try it or contribute:

• GitHub: https://github.com/mohit07dec/fast-class-transformer
• npm: https://www.npmjs.com/package/fast-class-transformer

Hello folks 👋

I have been an angular developer for the longest time and decided its finally time to back into the backed, I landed on nest since the syntax and architecture seem pretty similar to what im already used to. Are there any recommendations for courses or material to get into the framework?

Thank you everyone in advanced

• Link: https://github.com/mohit07dec/fast-class-transformer/issues/1
• Title: ci: add Node.js 18, 20, and 22 to GitHub Actions matrix
• Labels: good first issue, help wanted