Unit 1 - Practice Quiz

Node.js is not a framework or a language; it's a runtime environment that allows you to execute JavaScript code on the server-side, outside of a web browser, using Google's V8 engine.

The node -v or node --version command is the standard way to check the installed version of Node.js, which also confirms that it is installed and accessible in the system's PATH.

REPL is an interactive programming environment that takes single user inputs (Read), executes them (Evaluate), returns the result to the user (Print), and waits for the next input (Loop).

npm stands for Node Package Manager. It is the default package manager for Node.js and is used to install, update, and manage the packages (libraries, frameworks) that a project needs.

The npm init command starts an interactive process that prompts you for information about your project (like name, version, author) and then generates a package.json file to manage its metadata and dependencies.

Core modules are built into Node.js and do not need to be installed via npm. The http module is a core module for creating HTTP servers and clients. express, lodash, and react are popular third-party modules.

The EventEmitter is a core concept in Node.js that allows objects to emit named events that cause listener functions to be called. It's the foundation of Node's asynchronous, event-driven architecture.

Callbacks are a cornerstone of asynchronous programming in Node.js. They are used to defer an action until a previous, long-running operation (like a file read or network request) has completed.

Node.js uses an event-driven, non-blocking I/O model. This means it can handle many concurrent operations without waiting for any single one to complete, making it highly efficient and scalable.

The fs.readFileSync() method reads a file synchronously, which means it will block the rest of the code from executing until the entire file is read. Its asynchronous counterpart is fs.readFile().

The JSON.parse() method is a standard built-in function in JavaScript (and thus Node.js) that takes a JSON string as input and transforms it into a JavaScript object.

Instead of loading an entire large file into memory at once, streams allow you to read and process the data in small, manageable chunks. This makes the application more memory-efficient.

The zlib module provides data compression and decompression capabilities using the Gzip, Deflate/Inflate, and Brotli algorithms. It can be used with streams to efficiently compress or decompress data.

async/await is modern syntax for handling asynchronous operations. The await keyword can only be used inside an async function and it makes the function pause until the awaited Promise is complete.

Local modules are modules that you create within your own project. They are referenced using a relative file path (e.g., ./ or ../) to distinguish them from core or third-party modules.

The standard ways to exit the Node.js REPL are to use the .exit command or to press the Ctrl + C key combination twice.

package.json acts as the manifest file for a Node.js project. It contains the project's name, version, scripts, and, most importantly, the list of packages it depends on.

Since npm version 5, npm install <package-name> (or npm i <package-name>) automatically downloads the package and saves it as a dependency in package.json.

A Promise starts in the 'pending' state. From there, it can transition to either the 'fulfilled' state (representing success) or the 'rejected' state (representing failure). 'Executing' is not an official state of a Promise.

Node.js follows an error-first callback convention. The first argument to the callback is reserved for an error object. If the operation was successful, this argument will be null or undefined.

Node.js uses a single thread and an event loop. When an I/O operation (like waiting for a database query or a network request) starts, Node.js registers a callback and moves on to handle other requests instead of blocking the thread. This makes it extremely efficient for I/O-intensive applications with many concurrent connections, as the single thread is not tied up waiting.

The -g (or --global) flag installs the package globally, making its command-line tools available in the system's PATH. npm install nodemon --save-dev would install it as a development dependency for a specific project, and it would typically be run via an npm script (e.g., npm run dev), not directly from any terminal location.

The scripts object in package.json allows you to define command-line scripts. npm start is a shortcut for npm run start, which looks for a start key in the scripts object and executes its associated value as a shell command.

path is a built-in core module of Node.js for handling file paths. express is a popular web framework installed from the npm registry, making it a third-party module. myUtils is required using a relative path (./utils.js), indicating it is a local module created by the developer within the project.

The EventEmitter calls all listeners registered for a specific event in the order they were registered. First, the listener that logs Hello, Alice! is registered, then the one that logs Welcome!. When myEmitter.emit('greet', 'Alice') is called, both listeners are executed sequentially in their registration order.

The .once() method registers a listener that is invoked only the first time the event is emitted. After the first call to myEmitter.emit('specialEvent'), the listener is automatically removed. Subsequent emissions of the same event will have no effect on this specific listener.

While this pattern is non-blocking and allows for error handling, the deep nesting makes the control flow difficult to follow. This reduces code readability and makes it harder to debug, modify, and maintain, especially as more asynchronous steps are added. Modern solutions like Promises and async/await are used to flatten this structure.

The error-first pattern dictates that the first argument to the callback is a potential error object. The correct implementation is to check if err is not null first. If it is, you should handle the error and stop further execution (e.g., with return). Only if err is null should you proceed to use the data argument. Option A uses data before checking for an error, and Option B reverses the arguments.

fs.readFileSync() is a synchronous and blocking function. It halts the execution of the entire program until the file has been read completely. Therefore, 'Start' is logged, then the file is read and its content is assigned to data, then 'File content read' is logged, and finally 'End' is logged. The execution flow is strictly sequential.

fs.readFile() is asynchronous. When it's called, Node.js starts the file reading operation in the background and immediately continues executing the next line of code, which is console.log('End'). The callback function (which logs 'File content read') is only placed on the event queue once the file operation is complete, and it runs on a later tick of the event loop.

fs.appendFile() (and its sync version fs.appendFileSync()) is specifically designed to append data to a file. If the file does not exist, it is created. In contrast, fs.writeFile() would overwrite the entire file each time it is called. While fs.createWriteStream could also be used with a special flag, fs.appendFile is the most direct and simpler API for this common use case.

fs.readFile() reads the file content as a raw string. To use it as a JavaScript object and access its properties with dot notation (like config.port), you must first parse the JSON string into a JavaScript object using JSON.parse(). JSON.stringify does the opposite (object to string).

The primary advantage of streams is memory efficiency. fs.readFile() would attempt to load the entire 5GB file into the 1GB of RAM, causing the application to crash from memory exhaustion. fs.createReadStream() reads the file piece by piece (in chunks), allowing you to process the data as it arrives without ever holding the whole file in memory.

The .pipe() method is a powerful feature that takes a readable stream and connects it to a writable stream. It handles the data flow automatically, including backpressure (pausing the readable stream if the writable stream is too busy) and error handling, making it a very robust and efficient way to transfer data from a source to a destination.

The .pipe() method chains streams together in a sequence. The flow should be: 1. Read the source file (createReadStream). 2. Pipe the read data to the compression transform stream (createGzip). 3. Pipe the compressed output to the destination file (createWriteStream). Only the correct option represents this logical flow. The last option works but does not use streams, making it inefficient for large files.

The gzip and gunzip utilities are complementary. zlib.createGzip() creates a transform stream that compresses data using the gzip algorithm. To decompress this data, you must use the corresponding zlib.createGunzip() transform stream. createInflate is for the deflate algorithm, and createBrotliDecompress is for the Brotli algorithm.

The fs.promises API provides versions of fs methods that return Promises. The async/await syntax is designed to work with Promises. By declaring the function async, you can use await to pause its execution until the fs.readFile Promise resolves. The resolved value (data) is then returned from the async function, which implicitly wraps it in a new resolved Promise.

When a Promise that is being awaited rejects, it throws an error. The async/await syntax is designed so that these thrown errors can be caught using a standard JavaScript try...catch block. This provides a synchronous-looking way to handle asynchronous errors, significantly improving code readability and maintainability. While .catch() can also be used, try...catch is the conventional pattern for await.

Backpressure is a crucial flow-control mechanism in streams. If a readable stream produces data much faster than a writable stream can consume it, data would build up in a buffer, potentially leading to high memory usage. Backpressure allows the slow consumer (writable stream) to signal the fast producer (readable stream) to pause, preventing this buffer overflow. The .pipe() method handles backpressure automatically.

While package.json might specify a version range (e.g., ^1.2.3), package-lock.json records the exact version of every package that was installed. This guarantees that every developer on a team, as well as CI/CD pipelines, will have the identical set of dependencies, preventing "works on my machine" issues caused by minor version differences.

The newListener event is emitted before a listener is actually added to the internal array of listeners. In this code, when myEmitter.on('data', ...) is called for the 'Initial data listener', the newListener event handler fires. Inside this handler, we add another 'data' listener. This action itself triggers the newListener event again, creating an infinite recursion (on -> newListener -> on -> newListener ...). This will quickly exceed the maximum call stack size and cause the program to crash.

This question tests a deep understanding of the JavaScript event loop, microtasks, and macrotasks.

1. Synchronous code runs first: console.log(4) logs 4. setTimeout is a macrotask, scheduled for later.
2. async1() is called. console.log(1) logs 1.
3. await async2() is encountered. The async2 function is executed synchronously, so console.log(3) logs 3.
4. The await keyword pauses async1 and schedules the rest of it (console.log(2)) as a microtask to run after the current synchronous script finishes.
5. The Promise constructor is executed synchronously. console.log(6) logs 6. The .then() callback (console.log(7)) is scheduled as a microtask.
6. The last synchronous line, console.log(8), logs 8.
7. End of synchronous script. The event loop now processes microtasks. The await continuation (console.log(2)) is queued first, followed by the promise's .then() callback (console.log(7)).
8. Microtask queue is processed: console.log(2) logs 2, then console.log(7) logs 7.
9. Microtask queue is empty. The event loop now processes the macrotask queue. The setTimeout callback runs, and console.log(5) logs 5.
   Final Order: 4, 1, 3, 6, 8, 2, 7, 5.

This mechanism is called backpressure. When slowWritable.write() is called by pipe() and the writable's internal buffer exceeds its highWaterMark, write() returns false. The pipe() implementation listens for this return value. Upon receiving false, it calls fastReadable.pause(). The Readable stream stops emitting 'data' events. Later, when the Writable stream has processed its buffer and is ready for more data, it emits a 'drain' event. The pipe() implementation listens for this 'drain' event and calls fastReadable.resume() to continue the flow of data.

Node.js handles circular require() calls without infinite looping. When a.js requires b.js, execution of a.js pauses. Inside b.js, it requires a.js. To prevent a loop, Node.js returns an unfinished copy of a.js's exports object from the module cache. At that point, a.js has only executed up to exports.done = false;. Therefore, when b.js logs a.done, it sees false. Then b.js finishes its execution, fully populating its exports object. Execution returns to a.js, which now receives the completed exports from b.js, where b.done is true. Finally, a.js completes its execution.

This question tests the event loop's phase-specific execution order.

1. The fs.readFile callback executes during the I/O callbacks phase of the event loop.
2. Inside the callback, process.nextTick schedules a callback to the nextTick queue, which is processed immediately after the current operation completes, regardless of the current event loop phase.
3. setImmediate schedules a callback to run in the check phase, which comes after the I/O phase.
4. setTimeout with a 0ms delay schedules a callback for the timers phase of the next event loop tick.

Therefore, the order is:

1. The I/O callback runs: 'readFile'.
2. The nextTick queue is processed immediately: 'nextTick'.
3. The current I/O phase ends. The event loop proceeds to the check phase, executing the setImmediate callback: 'immediate'.
4. A new event loop tick begins, starting with the timers phase, executing the setTimeout callback: 'timeout'.

The key advantage of stream.pipeline is robust error handling. In the .pipe() chain (readable.pipe(gzip).pipe(writable)), if an error occurs in the writable stream (e.g., disk full), it will not automatically destroy the readable or gzip streams. This can lead to resource leaks, especially with file descriptors. stream.pipeline, however, ensures that if any stream in the pipeline emits an error, all other streams in the pipeline are properly destroyed and cleaned up, and the final callback is invoked with the error. This prevents resource leaks and provides a single, reliable place to handle errors for the entire chain.

fs.watch() is the more efficient and preferred method. It relies on the host operating system's native file change notification system (e.g., inotify on Linux, FSEvents on macOS, ReadDirectoryChangesW on Windows). This is very efficient as the OS directly notifies the Node.js process of changes. In contrast, fs.watchFile() is a fallback mechanism that works on any platform by periodically calling fs.stat() on the file at a specified interval and comparing the results. This constant polling is much less efficient and consumes more CPU/disk resources, especially when watching many files.

npm install is designed for adding/updating dependencies. It can read package.json and update package-lock.json if it finds newer compatible versions based on semver ranges (e.g., ^1.2.3). This can lead to inconsistencies in CI/CD environments. npm ci (Clean Install) is designed for deterministic builds. It requires a package-lock.json or npm-shrinkwrap.json file. It will throw an error if the dependencies in package.json and package-lock.json do not match. Its primary purpose is to install dependencies that exactly match the lock file, ensuring a reproducible build environment, which is why it's recommended for automated environments.

Loading a 5GB file entirely into memory will almost certainly exceed the default V8 heap size limit and crash the Node.js process. Options A, B, and D all attempt to load the entire file content into memory before parsing. Option B (require) is also synchronous and reads the whole file. The only memory-efficient solution is to use streams. A standard fs.createReadStream provides raw chunks of data, which are not valid JSON on their own. Therefore, you must pipe this stream into a specialized third-party streaming JSON parser. These parsers can identify object boundaries within the stream and emit individual, fully-formed objects as they are parsed, allowing you to process a massive file with a very small memory footprint.

The await keyword does not require its operand to be a Promise. If await is used with a non-Promise value, it effectively wraps that value in a resolved Promise (Promise.resolve('a non-promise value')) and then awaits that. The execution flow is:

1. test() is called.
2. 'start' is logged.
3. await is encountered. It schedules the rest of the async function (the two console.log calls) to run as a microtask after the current synchronous code block finishes.
4. Execution continues outside test(), and 'after call' is logged.
5. The synchronous block is done. The event loop processes the microtask queue.
6. The rest of the async function runs. result gets the value 'a non-promise value', which is logged. Then 'end' is logged.

The special REPL variable _ always holds the result of the last synchronously evaluated expression. The fs.readFile call is asynchronous. It returns undefined immediately and its callback executes later. The last expression to be synchronously evaluated by the REPL is x * 5, which results in 50. Therefore, _ will be set to 50. The result of the asynchronous file read operation does not affect the _ variable.

Node.js maintains a module cache (require.cache). The key for this cache is the module's fully resolved, absolute filename. When you call require('./module.js'), Node.js first resolves it to /full/path/to/project/module.js. It checks the cache for this key. If not found, it loads, executes, and caches the module. The second call, require('/full/path/to/project/module.js'), uses the same resolved path. Since this key is now in the cache, Node.js returns the cached exports object directly without re-executing the file. Therefore, module1 and module2 point to the exact same object in memory, and the comparison === yields true.

The 'error' event is a special case for EventEmitter. If an 'error' event is emitted and no listener has been registered for it using .on('error', ...) or .once('error', ...), the default behavior is to treat it as a fatal exception. The error object is thrown, which will bubble up and, if unhandled, crash the Node.js process. This is a deliberate design choice to prevent silent failures and force developers to handle errors explicitly.

This question assesses the understanding of I/O strategies in a performance-critical context.

• fs.writeFileSync is synchronous and will block the event loop for the duration of the disk write, which is terrible for a server's concurrency.
• Aggregating in memory can introduce latency (waiting for the buffer to fill) and can lead to high memory usage.
• worker_threads are good for CPU-bound tasks, not I/O-bound tasks. The I/O itself is already non-blocking in Node; a worker thread adds overhead for this use case.
• Asynchronous stream-based processing is the canonical Node.js solution. It processes data in small chunks as they arrive, keeping memory usage low and the event loop free to handle other requests. Transform streams are ideal for this, as they allow for immediate, in-line processing (e.g., parsing, encrypting) of data flowing from a readable source to a writable destination.

NPM uses a hierarchy of configuration files. The default values for the npm init command are sourced from the user's configuration. You can set these defaults by running commands like npm config set init.author.name "Your Name", npm config set init.author.email "your@email.com", and npm config set init.license "MIT". These commands will write the corresponding values to your user-level ~/.npmrc file, and npm init will use them as suggestions in all future projects.

This pattern is prone to file descriptor leaks. Operating systems have a finite number of file descriptors a process can open. In this code, fs.close(fd) needs to be called to release the descriptor. If it's only called on the successful execution path, any error (an error in fs.write, or a synchronous error in the 'complex logic' part) could cause the execution to bypass the fs.close call. In a server, this would mean that over time, the application would accumulate open file descriptors until it hits the system limit and can no longer open any new files, causing it to fail. The robust way to handle this is with a try...finally block (or its equivalent in promise/async-await syntax) to ensure fs.close is always called.

Promise.all is all-or-nothing. It waits for all promises to resolve, but if any promise in the input array rejects, Promise.all immediately rejects with the reason of the first promise that rejected. In this case, p2 rejects, so the catch block for Promise.all is executed, logging 'all_err: Error 2'.

Promise.allSettled, on the other hand, never rejects. It waits for all promises to either resolve or reject and then resolves with an array of objects, each describing the outcome of a promise. Each outcome object has a status ('fulfilled' or 'rejected') and either a value (if fulfilled) or a reason (if rejected). Therefore, the try block for Promise.allSettled succeeds, and logging the status of each result gives ['fulfilled', 'rejected', 'fulfilled'].

peerDependencies are used for plugins or libraries that require a specific version of a 'host' package. For example, a React component library would list react as a peer dependency. The library itself doesn't bundle React; it expects the final application (the consumer) to have React installed. In older npm versions (v3-6), if a peer dependency was missing or the wrong version was installed, npm would only print a warning during installation. A significant change in npm v7 is that it now enforces peerDependencies by default. If it cannot find a valid peer dependency in the tree, it will attempt to install it. If it finds a conflict that it cannot resolve, the installation will fail.

The callback function in _transform is crucial for flow control. The stream machinery will not send the next chunk of data to _transform until this callback is invoked. This allows for both synchronous and asynchronous processing within the transform. If you were doing an async operation (like a database lookup) with the chunk, you would call the callback inside the async operation's own callback. If you fail to call the callback, the stream will stall permanently. You can also pass an error object to the callback (callback(new Error('...'))) to signal that processing failed, which will emit an 'error' event on the stream.

A fundamental contract of Node.js callbacks is that they should be called exactly once. If a function violates this, it breaks the assumptions of the calling code. In the given example, the callback might be called first with 'Success' and then immediately after with an Error. The calling code is written to handle either an error or a result, but not both. This would lead to the console.log(result) statement executing, followed by the console.error(err.message). This could lead to severe bugs, like writing a success record to a database and then an error record for the same operation, or trying to send an HTTP response twice to the same request.