What are the modules in Node.js?

You need to read a config file at startup. How do you import the 'fs' module and use readFileSync? What if the file doesn't exist?

A teammate wrote a helper file with 'module.exports = { parseDate }'. In your file, you write 'const { parseDate } = require('./helpers')' but get undefined. What's wrong?

You're setting up a new Node project and see 'type': 'module' in package.json. How does that change how you write imports compared to a project without it?

You're incrementally migrating a CommonJS codebase to ESM. A file uses 'require('./config')' where config.js uses 'module.exports = {...}'. After renaming config.js to config.mjs and changing to 'export default {...}', the import breaks. Why?

A service you own starts throwing 'ERR_MODULE_NOT_FOUND' for a dependency that definitely exists in node_modules. Walk me through how you'd debug the module resolution.

Your team debates using dynamic import() for a rarely-used heavy module (like a PDF generator) vs static import at top of file. What factors drive the decision?

Design a plugin system where external packages register themselves via a 'plugins' field in package.json. How do you safely load and validate each plugin at runtime without crashing the host process?

A large monorepo has circular dependencies between internal packages (pkg-a imports pkg-b, pkg-b imports pkg-a). How does Node's module cache handle this, and what patterns prevent runtime surprises?

You're evaluating whether to adopt ESM across a 50-service backend. What's the migration strategy that avoids a flag-day cutover, and how do you handle transitive dependencies that haven't published ESM builds?

Your org maintains a shared internal module registry. Teams publish v1, v2, v3 of 'core-utils' with breaking changes. How do you design module resolution and versioning policy so services can upgrade independently without diamond dependency conflicts?

You're architecting a micro-frontend platform where each team deploys a separate Node-based SSR fragment. How do you define module boundaries and shared dependencies (React, design system) to avoid version skew and duplicate downloads?

A legacy CommonJS codebase has 200k lines and zero tests. Leadership wants ESM for top-level await and tree-shaking. Propose a multi-quarter migration plan that delivers incremental value and doesn't block feature work.