Git & Project Management

// package.json allows a range of versions
"dependencies": { "express": "^4.18.0" }

// package-lock.json pins the exact resolved version and its full dependency tree
"express": {
  "version": "4.18.2",
  "resolved": "https://registry.npmjs.org/express/-/express-4.18.2.tgz"
}

Common follow-ups: What's the difference between 'npm install' and 'npm ci' regarding how they use (or don't use) package-lock.json?;Why is it considered bad practice to manually edit package-lock.json by hand?

// package.json at the repo root
{
  "workspaces": ["packages/*"]
}

// packages/api/package.json can depend on a sibling package directly
"dependencies": { "@myorg/shared-utils": "workspace:*" }

Common follow-ups: What's the tradeoff between a monorepo and separate repositories for related but independently deployable services?;How does a tool like Turborepo's build caching actually determine which packages need to be rebuilt after a given change?

// package.json
"husky": { "hooks": { "pre-commit": "lint-staged" } },
"lint-staged": { "*.js": ["eslint --fix", "prettier --write"] }

// This automatically lints and formats only the files being committed,
// before the commit is actually allowed to complete

Common follow-ups: Why does lint-staged specifically run checks only against staged files rather than the entire codebase on every commit?;What's the risk of a pre-commit hook that takes too long to run, and how do teams balance thoroughness against developer friction?

// package.json version ranges leveraging semver conventions
"dependencies": {
  "lodash": "^4.17.0", // accepts any 4.x.x update, but not 5.0.0
  "express": "~4.18.0" // accepts only patch updates within 4.18.x
}

Common follow-ups: What's the practical consequence for downstream consumers when a maintainer violates semver conventions like this?;How do automated tools like semantic-release determine the appropriate version bump automatically based on commit messages?

feat: add support for refresh token rotation
fix: correct off-by-one error in pagination
docs: update README with new API examples
feat!: remove deprecated v1 authentication endpoints

BREAKING CHANGE: the /v1/auth endpoints have been removed; use /v2/auth instead

Common follow-ups: How does semantic-release determine whether to publish a patch, minor, or major version based on the commit history since the last release?;What happens if a team's commits don't consistently follow the convention -- does the automation simply fail silently?

# .gitignore
node_modules/
.env
.env.local
dist/
*.log
coverage/

Common follow-ups: What's the correct process for removing a sensitive file from Git history after it's already been committed and pushed?;Why shouldn't node_modules ever be committed, even though it would technically make cloning and running the project 'simpler'?

# GitHub branch protection settings (conceptual, configured via the UI or API)
required_status_checks: ['test', 'lint', 'build']
required_approving_review_count: 1
enforce_admins: true
restrict_pushes: true # no direct pushes to main, only via pull request

Common follow-ups: Should branch protection rules apply equally to repository administrators, or is an exception sometimes justified?;How do you handle an urgent hotfix that needs to bypass the normal review process during an active incident?

git bisect start
git bisect bad HEAD           # current commit exhibits the bug
git bisect good v1.2.0        # this earlier tagged commit was known good

# Automated: runs a test script at each step to determine good/bad automatically
git bisect run npm test

Common follow-ups: What makes a good automated test script for 'git bisect run', and what specific exit codes does it need to return?;What happens if a commit within the bisected range simply doesn't build or can't be tested at all?

# All three achieve a similar end result with different mechanics
npm install
yarn install
pnpm install  # uses a global content-addressable store, hard-linked per project

Common follow-ups: What's the tradeoff or compatibility consideration when switching an existing project from npm to pnpm, given pnpm's stricter node_modules structure?;How does pnpm's approach affect a project's build reproducibility compared to npm or Yarn?

{
  "dependencies": { "express": "^4.18.0" }, // needed at runtime by consumers
  "devDependencies": {
    "jest": "^29.0.0",      // only needed for running this project's own tests
    "eslint": "^8.0.0"      // only needed for linting during development
  }
}

Common follow-ups: What's the purpose of a third category, peerDependencies, and when should a package use it instead of a regular dependency?;How does 'npm install --production' or 'npm ci --omit=dev' leverage this distinction in a deployment context?