15 questions found
What is a pull request template, and how does it help standardize code review in a Node.js team's Git workflow?
Intermediate
A pull request template is a pre-filled markdown file (stored in the repository, typically under .github/PULL_REQUEST_TEMPLATE.md) that automatically populates the description field whenever a new pull request is opened, prompting the author with structured sections (what changed, why, how it was tested, screenshots if relevant) -- this ensures every PR includes the context a reviewer needs, rather than relying on each individual contributor to remember to include it consistently.
<!-- .github/PULL_REQUEST_TEMPLATE.md -->
## What changed
## Why
## How was this tested?
## Checklist
- [ ] Tests added/updated
- [ ] Documentation updated
- [ ] No console.log statements left in
Real-world example
A team notices code review quality and speed improve noticeably after introducing a PR template requiring authors to explicitly describe their testing approach, since reviewers no longer need to ask basic clarifying questions that used to slow down every review cycle.
Common follow-ups: How do you balance a PR template being thorough enough to be useful without becoming tedious boilerplate contributors start ignoring?;How might a PR template differ for a documentation-only change versus a significant feature addition?
engineering:code-review;Testing with Jest
Mocha & the Node Test Runner
How would you use Git tags in combination with a CI/CD pipeline to trigger a production release of a Node.js application?
Advanced
Tagging a specific commit with a version identifier (like v1.2.3) creates an immutable reference to that exact point in history -- a CI/CD pipeline can be configured to trigger a production deployment workflow specifically when a new tag matching a version pattern is pushed, distinct from the regular CI checks that run on every commit or pull request, providing a clear, deliberate, and auditable trigger for exactly when and what gets deployed to production.
# .github/workflows/release.yml
on:
push:
tags: ['v*.*.*']
jobs:
deploy:
steps:
- uses: actions/checkout@v4
- run: docker build -t myapp:${{ github.ref_name }} .
- run: ./deploy-to-production.sh
Real-world example
A team's production deployments only happen when a maintainer explicitly creates and pushes a version tag like v2.3.0, giving a clear, deliberate, and fully auditable record of exactly which commit corresponds to each production release, distinct from the continuous merges happening to the main branch.
Common follow-ups: What's the difference between an annotated Git tag and a lightweight tag, and which is generally recommended for release tagging?;How would you handle rolling back to a previous tagged release if the newly deployed version has a critical bug?
CI/CD
Publishing & Deployment;Deployment & Process Managers (PM2)
What is the purpose of an npm 'scripts' section in package.json, and how do custom scripts standardize common project tasks across a team?
Intermediate
The scripts section defines named shell commands runnable via 'npm run <name>', standardizing common tasks (starting the dev server, running tests, linting, building) behind consistent, memorable names rather than requiring every developer to remember the exact underlying command-line invocation and its specific flags, and making these tasks trivially runnable the same way in both local development and CI pipelines.
{
"scripts": {
"dev": "nodemon server.js",
"test": "jest --coverage",
"lint": "eslint . --fix",
"build": "tsc && webpack --mode production"
}
}
Real-world example
A new developer joining a project runs 'npm run dev' to start the development server and 'npm test' to run the test suite, without needing to know or remember the specific underlying tools (nodemon, jest) or their exact command-line flags, since the scripts section abstracts all of that away consistently for the whole team.
Common follow-ups: How would you chain multiple scripts together, like running the linter and then the tests in sequence with a single command?;What are npm's built-in 'pre' and 'post' script hooks, like 'pretest', and how do they run automatically?
CLI Tools & Scripting with Node.js;Testing with Jest
Mocha & the Node Test Runner
How would you handle a Node.js project's dependency vulnerabilities reported by 'npm audit' as part of a CI/CD pipeline?
Advanced
npm audit checks a project's installed dependencies against a database of known security vulnerabilities, reporting affected packages and their severity -- integrating 'npm audit --audit-level=high' (or a similar threshold) as a CI pipeline step can automatically fail a build if a sufficiently severe vulnerability is detected, though teams typically need a documented process for handling cases where a vulnerable dependency has no available fix yet, since blocking every build indefinitely on an unfixable transitive dependency isn't practical.
# CI pipeline step
npm audit --audit-level=high
# If this exits non-zero (vulnerabilities found at or above 'high' severity),
# the CI build fails, requiring the team to address or explicitly accept the risk
Real-world example
A team's CI pipeline automatically fails any build introducing a new high-or-critical severity vulnerability via a dependency update, catching a compromised or vulnerable package version before it ever reaches a deployed environment, while maintaining a documented exception process for rare cases with no available fix.
Common follow-ups: What's the difference between 'npm audit fix' and 'npm audit fix --force', and why is the latter riskier to run automatically?;How do you handle a genuinely unfixable vulnerability in a transitive dependency that has no patched version available?
Security;CI/CD
Publishing & Deployment
What is the purpose of a CHANGELOG.md file in a Node.js project, and what should typically be included in each entry?
Beginner
A CHANGELOG.md documents notable changes for each released version in a human-readable format, typically grouped by category (Added, Changed, Fixed, Removed, Breaking Changes) and version number, letting users and downstream consumers of a package quickly understand what changed between versions without needing to read through the full commit history themselves, which is especially valuable when deciding whether it's safe to upgrade.
## [2.1.0] - 2026-01-15
### Added
- Support for refresh token rotation
### Fixed
- Off-by-one error in pagination results
### Breaking Changes
- Removed deprecated v1 authentication endpoints
Real-world example
A team evaluating whether to upgrade a critical dependency checks its CHANGELOG.md first, quickly identifying that the new version includes a breaking change to an API they rely on, letting them plan the necessary code changes before upgrading rather than discovering the break after deployment.
Common follow-ups: How does a tool like semantic-release or standard-version automatically generate this file from conventional commit messages?;What's the risk of a changelog that's manually maintained and inconsistently updated compared to an automated one?
npm & Packages;CI/CD
Publishing & Deployment