Webpack Interview Questions

1. What is Webpack, and how does it differ from Grunt and Gulp?

Webpack is a powerful module bundler that treats every asset in a project as a module. It transforms non-browser-compatible files using loaders, injects custom logic at build stages via plugins, and packages all dependent modules into browser-executable bundles. Its core function is to analyze project structure, locate JavaScript modules and other extension languages (like TypeScript or JSX) that browsers can’t run natively, then bundle them into appropriate formats for browser consumption.

Grunt and Gulp are task runners focused on optimizing frontend development workflows. They operate by defining a series of sequential tasks (such as compiling SASS, minifying files, or concatenating code) in a configuration file, then executing these tasks automatically. In contrast, Webpack takes a holistic approach: starting from a designated entry file (e.g., main.js), it recursively resolves all dependent modules, processes each with configured loaders, and outputs one or more browser-ready bundles. Unlike task runners which require developers to split the build process into discrete tasks and manage their execution order, Webpack only needs clear entry points and correct loader/plugin mappings for different resource types.

2. Advantages and Disadvantages of Webpack

Advantages:

• Optimized for modular projects, offering out-of-the-box support for modern module systems (ES6, CommonJS, AMD).
• Highly extensible through a rich ecosystem of plugins, enabling custom build logic tailored to project needs.
• Boasts a large, active community that regularly introduces new features and maintains up-to-date tooling.
• Provides a seamless development experience with features like hot module replacement and dev server integration. Disadvantage: It is primarily designed for modular projects, making it less intuitive or efficient for non-modular legacy codebases.

3. Explain the concepts of Bundle, Chunk, and Module in Webpack

• Module: The smallest unit of code in a project, typically corresponding to a single file (e.g., a JavaScript module or a CSS file). Webpack starts from the entry point and recursively resolves all dependent modules.
• Chunk: A logical group of modules grouped together during the build process, usually centered around an entry point or created via code splitting. Chunks serve as intermediate units before being converted into bundles.
• Bundle: The final output file generated by Webpack. Each bundle is derived from one or more chunks and contains browser-executable code or assets.

4. What are Loaders and Plugins in Webpack? What’s the difference?

• Loader: A module transformer that converts the source code of a module into a browser-compatible format. For example, babel-loader transpiles ES6+ code to ES5, css-loader resolves CSS imports, and image-loader compresses image assets. Loaders operate at the individual module level during the initial parsing phase.
• Plugin: An extension that injects custom logic at specific stages of Webpack’s build lifecycle. Plugins can perform tasks that loaders can’t, such as bundle optimization, asset management, or environment variable injection. A valid plugin is an object with an apply method that registers hooks with Webpack’s compiler to execute custom actions.

The key difference: Loaders process individual modules and transform their content, while plugins work across the entire build pipeline, modifying the overall build output or workflow.

5. What is Hot Module Replacement (HMR)?

Hot Module Replacement is a Webpack feature that updates modified modules in the browser without requiring a full page reload, preserving application state and speeding up development. It’s an enhanced alternative to automatic browser refresh.

To enable HMR, configure the dev server and include the HMR plugin:

const webpack = require('webpack');
const path = require('path');

const isDev = process.env.NODE_ENV === 'development';

module.exports = {
  mode: isDev ? 'development' : 'production',
  devServer: {
    hot: isDev,
    static: path.resolve(__dirname, 'public')
  },
  plugins: [
    ...(isDev ? [new webpack.HotModuleReplacementPlugin()] : [])
  ]
};

6. List common Webpack Plugins and Loaders

Popular Plugins:

• html-webpack-plugin: Generates HTML files with injected bundle references, eliminating manual script tag updates.
• mini-css-extract-plugin: Extracts CSS code from JavaScript bundles into standalone CSS files, enabling separate caching and loading.
• clean-webpack-plugin: Removes old build files from the output directory before each new build.
• HotModuleReplacementPlugin: Enables hot module replacement during development.
• copy-webpack-plugin: Copies static assets (like images or fonts) from the source directory to the output directory.
• terser-webpack-plugin: Minifies and compresses JavaScript code, supporting ES6+ syntax.

Essential Loaders:

• css-loader: Resolves CSS imports and supports features like modularization and minification.
• image-webpack-loader: Optimizes and compresses image files (JPEG, PNG, SVG) to reduce bundle size.
• babel-loader: Transpiles ES6+ and JSX code to ES5 using Babel.
• style-loader: Injects CSS code into the DOM via JavaScript, applying styles dynamically.
• file-loader: Emits files to the output directory and returns they relative URLs for use in code.
• source-map-loader: Loads external source map files to enable precise debugging in the browser.

7. How can Webpack configuration files be generated automatically?

Automated Webpack configuration can be created using scaffolding tools such as webpack-cli (via webpack init), Vue CLI, Create React App, or Angular CLI. These tools generate pre-configured Webpack setups tailored to specific frameworks or project types, eliminating the need for manual configuration.

8. What’s the difference between webpack-dev-server and traditional HTTP servers like Nginx?

webpack-dev-server is a development-specific server that stores bundled files in memory instead of writing them to disk, enabling faster rebuilds. It also integrates seamlessly with Hot Module Replacement to update modules without full page reloads, making it more efficient for iterative development. In contrast, Nginx is a production-grade web server focused on serving static files, handling reverse proxy, and optimizing performance for live applications. It lacks built-in support for HMR and in-memory bundling, which are critical for development workflows.

9. Describe the Webpack build process

1. Start from the entry module(s) defined in the configuration file, recursively resolving all dependent modules.
2. For each resolved module, apply the corresponding loaders as configured to transform its content into a compatible format.
3. After processing, resolve any dependencies of the current module and repeat the loader application process for those modules.
4. Group modules into chunks based on entry points and code splitting rules; each entry point and its depednencies form a single chunk.
5. Convert all chunks into output files (bundles) and write them to the specified output directory.
6. Throughout the entire build lifecycle, execute the logic defined by plugins at predefined hooks (e.g., before compilation, after bundle output).

10. What are entry and output in Webpack?

• Entry: Specifies the module(s) where Webpack starts building its dependency graph. By default, it’s set to ./src/index.js, but multiple entry points can be defined for multi-page applications.
• Output: Defines the directory path and filename pattern for the bundled files generated by Webpack. The default output directory is ./dist, but this can be customized to any location, along with dynamic filenames using placeholders (like [name].bundle.js).

11. How to configure Webpack for single-page and multi-page applications?

// Single-page application configuration
module.exports = {
  entry: './src/main.js',
  output: {
    filename: 'bundle.js',
    path: path.resolve(__dirname, 'dist')
  }
};

// Multi-page application configuration
module.exports = {
  entry: {
    home: './src/pages/home.js',
    checkout: './src/pages/checkout.js',
    profile: './src/pages/profile.js'
  },
  output: {
    filename: '[name].bundle.js',
    path: path.resolve(__dirname, 'dist')
  }
};

12. What is long-term caching, and how to optimize it in Webpack?

Long-term caching is a browser optimization where static assets are stored locallly, reducing repeated downloads. To ensure browsers only fetch updated assets when code changes, we need unique filenames for modified bundles.

In Webpack, long-term caching can be optimized using:

• Content hashing: Use [chunkhash] or [contenthash] in output filenames to generate unique hashes based on file content (e.g., [name].[contenthash].js). This ensures unchanged files retain the same hash, allowing browsers to reuse cached versions.
• Code splitting: Separate vendor code (like React or Lodash) from application code using splitChunks optimization. Vendor code changes less frequently, so it can be cached independently.
• Stable module IDs: Use HashedModuleIdsPlugin to generate consistent module IDs based on module content instead of arbitrary order, preventing unnecessary hash changes when module order shifts.

Git Interview Questions

1. What are the key differences between Git and SVN?

The core difference is that Git is a distributed version control system (DVCS), while SVN is a centralized version control system (CVCS).

• Offline functionality: Git allows developers to perform all version control operations (commit, branch, merge) locally without an internet connection, synchronizing with remote repositories only when needed. SVN requires constant connectivity to a central server for most operations.
• Data storage: Git stores data as snapshots of the entire repository at each commit, whereas SVN tracks changes as delta modifications to individual files.
• Accessibility: Git repositories can be easily shared publicly or privately, while SVN repositories are typically restricted to internal networks due to their centralized nature.
• Dependency on server: Git does not rely on a central server; if the remote repository is unavailable, developers can continue working locally. SVN operations are completely dependent on the central server, which halts work if the server goes down.
• Version numbering: SVN uses a sequential global version number for each commit, while Git uses unique SHA-1 hashes for commits with no global linear numbering.

2. Describe the basic Git workflow

1. Modify files: Make changes to files in the local working directory.
2. Stage changes: Use git add to move modified files to the staging area, preparing them for commit.
3. Commit changes: Use git commit to save the staged changes to the local repository with a descriptive commit message.
4. Sync with remote: Use git push to upload local commits to the remote repository, or git pull to fetch and merge remote changes into the local branch.

3. Explain the differences between git fetch, git merge, and git pull

• git fetch: Downloads the latest commits, branches, and tags from the remote repository to the local repository but does not merge them into the current working branch. It updates the remote-tracking branches (e.g., origin/main) without affecting the local working copy.
• git merge: Combines changes from a specified branch into the current active branch. It creates a new merge commit if there are conflicting changes.
• git pull: A combination of git fetch and git merge. It first fetches the latest remote changes, then automatically merges them into the current working branch. This can lead to unexpected merge conflicts if not used carefully.

4. List common Git branch commands

• Create a branch: git branch feature/login
• List all local branches: git branch
• Switch to an existing branch: git checkout feature/login or git switch feature/login
• Create and switch to a new branch: git checkout -b feature/payment or git switch -c feature/payment
• Merge a branch into the current branch: git merge feature/login
• List merged branches: git branch --merged
• List unmerged branches: git branch --no-merged
• Delete a merged branch: git branch -d feature/login
• Force delete an unmerged branch: git branch -D feature/login

5. What’s the difference between git merge and git rebase?

Both commands are used to integrate changes from one branch into another, but they handle commit history differently:

• git merge: Creates a new merge commit that combines the histories of the two branches. It preserves the original commit history, making it easy to track when branches were merged. This is safe to use on public branches as it doesn’t modify existing commits.
• git rebase: Replays commits from the current branch onto the base branch, creating a linear commit history. It modifies existing commits and rewrites the commit history, which can make the history cleaner but should never be used on public branches (as it will cause conflicts for other developers).

6. How to resolve merge conflicts?

Merge conflicts occur when Git can’t automatically merge changes from two branches (e.g., same line modified in both branches). To resolve conflicts:

1. Run git status to identify files with conflicts.
2. Open the conflicting file in an editor; Git marks conflicting sections with <<<<<<<, =======, and >>>>>>>.
3. Edit the file to resolve the conflict by keeping the desired changes and removing the conflict markers.
4. Stage the resolved file with git add <filename>.
5. Commit the resolved changes with git commit.
6. Use git log --graph to visualize the merged commit history.

7. Git Configuration Basics

Git configuration can be set at three levels:

• System level: Applies to all users on the machine, stored in /etc/gitconfig (Linux/macOS) or C:\Program Files\Git\etc\gitconfig (Windows). Use git config --system to modify.
• Global level: Applies to the current user, stored in ~/.gitconfig (Linux/macOS) or C:\Users\<User>\.gitconfig (Windows). Use git config --global to modify.
• Local level: Applies to the current repository, stored in .git/config. Use git config --local to modify.

Common configurations include setting username and email:

git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"

8. List commonly used Git commands

# Clone a remote repository
git clone https://github.com/username/repo.git

# Stage changes: single file or all files
git add filename.js
git add .

# Commit staged changes with a message
git commit -m "Fix login form validation"

# Push local commits to remote branch
git push origin main

# Fetch and merge remote changes to local branch
git pull origin main

# View commit history (simplified or detailed)
git log --oneline
git log --graph --decorate --all

# View all operation history (including resets)
git reflog

# Check current working directory status
git status

# View Git version
git --version

# View current configuration
git config --list

# Initialize a new Git repository in current directory
git init

# Reset to a specific commit (discard local changes)
git reset --hard 8a3e9f

# View changes made to a file before staging
git diff filename.js

# Delete a file and stage the deletion
git rm filename.js

# Restore a deleted file or unstage changes
git checkout -- filename.js

# Associate local repository with a remote repository
git remote add origin https://github.com/username/repo.git

# Remove association with a remote repository
git remote remove origin

# Create a new branch
git branch feature/dashboard

# List all local branches
git branch

# Switch to an existing branch
git switch feature/dashboard

# Create and switch to a new branch
git switch -c feature/analytics

# Stash uncommitted changes temporarily
git stash

# Apply the most recent stash
git stash apply

# Merge a specific branch into current branch
git merge feature/dashboard

# List remote branches
git branch -r

# Force delete an unmerged branch
git branch -D feature/old

# Delete a remote branch
git push origin --delete feature/old

# Create a compressed archive of a branch
git archive --format=zip main -o archive.zip

9. What is a fork? How does it differ from a branch and a clone?

• Fork: A personal copy of someone else’s remote repository, hosted on the same platform (e.g., GitHub or GitLab). Forking allows developers to modify the code without affecting the original repository, and submit changes via pull requests.
• Branch: A lightweight, independent line of development within a single repository. Branches are used to work on features or fixes without impacting the main codebase, and can be merged back into the main branch once complete.
• Clone: A local copy of a remote repository, downloaded to the developer’s machine. Cloning allows offline work and synchronization with the remote repository, but it does not create a separate remote copy like a fork does.

10. When should you use git stash?

git stash is used to temporarily save uncommitted changes in the working directory, allowing you to switch branches or perform other Git operations without committing incomplete work. It’s particularly useful when you need to:

• Switch to another branch to fix an urgent bug without committing your current in-progress work.
• Pull the latest changes from the remote repository without stashing local changes first.
• Clean the working directory while preserving incomplete changes for later use.

To retrieve stashed changes, use git stash apply or git stash pop (which removes the stash after applying).