In the previous lesson you followed a cycle you know well: write code, save, run node src/catalog.js, read the output, fix, repeat. That cycle is fine for building a program, but it is painfully slow when what you want is to answer a small question: how does reduce behave with this array? What exactly does Object.entries return for a session? What is the total capacity of the Auditorio Ribera?

That is what the REPL is for: an interactive interpreter where you type an expression and see the result instantly. It is one of the most underrated tools in the ecosystem and, used well, it saves hours. In this lesson you will learn to handle it fluently and to explore Escena Viva's data live before writing it into a script.

1. What a REPL is and what it is for
2. Starting the REPL and evaluating expressions
3. The _ variable and the result of declarations
4. Autocompletion, history and navigation
5. The dot commands
6. Loading the Escena Viva catalog into the REPL
7. Exploring and transforming the data live
8. The .editor mode for multi-line functions
9. Running one-off code without the REPL: node -e and node -p
10. Quirks: promises, top-level await and other surprises
11. When to use the REPL and when not to

REPL stands for Read-Eval-Print-Loop. It is a loop that:

1. Reads (Read) what you type.
2. Evaluates (Eval) it as JavaScript code.
3. Prints (Print) the result.
4. Loops (Loop) round, waiting for the next line.

It is not a Node peculiarity: the browser console is a REPL, and so are python, irb and psql. Their value lies in the zero cost of experimenting: trying something out requires no files and no remembering paths.

Real day-to-day uses:

• Checking the exact behavior of an array method you do not use often.
• Verifying a regular expression before putting it into your code.
• Exploring the shape of some data you have just received.
• Converting values quickly (dates, cents to euros, bytes to megabytes).
• Checking what an installed module exports, without reading its documentation.

Type node with no arguments:

The > symbol means the REPL is waiting for a line. Try:

The REPL keeps state between lines: the variables you declare go on existing.

It also works with multi-line code: if a line is incomplete, the prompt changes to ... and the REPL waits for you to close it.

To leave: .exit, or Ctrl+D, or Ctrl+C twice.

You will have noticed something puzzling: when you typed const venue = 'Auditorio Ribera' the REPL answered undefined. That is not an error. The REPL prints the value of the expression it evaluated, and in JavaScript a variable declaration produces no value at all: it produces undefined.

The same happens with function, class, loops and console.log (which returns undefined after printing):

The first line is what console.log printed; the second is its return value. In time you stop noticing it.

_ holds the result of the last expression evaluated. It is wonderfully handy for chaining explorations without declaring intermediate variables.

There is a sibling variable, _error, which holds the last error thrown:

Careful: if you manually assign _ = 5, you lose this feature for that session (the REPL warns you). Avoid using _ as a variable name of your own.

These keys turn the REPL into something genuinely fast:

Autocompletion is the jewel. Type an object and a dot, then press Tab:

It also works with built-in modules, which turns it into instant documentation:

The history is kept between sessions in the file ~/.node_repl_history. You can close the REPL, open it tomorrow and get back with ↑ whatever you tried today.

Anything starting with . in the REPL is an instruction to the REPL itself, not JavaScript.

An example of the full .load / .save cycle:

.save writes out every line you typed (not the results). It is a convenient way to rescue an exploration that went well and turn it into the starting point of a script.

.break rescues you from the classic dead end:

Without .break (or Ctrl+C), the REPL would wait forever for the closing brace.

.clear deserves a warning: it resets the context and you lose every variable you defined. Use it when you want to start from scratch, not by accident.

Here is where .load earns its keep. We are going to prepare a file containing only the data, with no presentation logic and no argument filtering, so that we can load it cleanly into the REPL.

Create src/catalog-data.js:

Now, from the project root:

The REPL shows the contents of the file as it evaluates it line by line. When it finishes, the catalog constant exists in your session:

An important point: .load is not the same as require. .load copies and evaluates the text of the file inside the REPL's context, as if you had typed it. require loads an isolated module and gives you only what that module exports. That is why .load works even when the file exports nothing, and why it is the ideal tool for exploring. Real modules arrive in Module 2.

With the catalog loaded, the fun begins: trying transformations out before writing them into the script.

To inspect a nested object without Node truncating it with [Object]:

The sessions are nested inside each event. To work with all of them at once:

And if we need to know which event each one belongs to, we add that information while flattening:

The ... (spread) operator copies every property of the original object and adds the new ones. We will study it formally in the next lesson.

Sixty-four thousand two hundred and eighty-six euros of accumulated revenue. This is exactly the kind of question you answer in twenty seconds in the REPL and would take five minutes to code, save and run.

Note the [...sessions] before sort: sort mutates the original array. Copying it first avoids altering the data you are exploring. It is a classic mistake that the REPL helps you discover.

The ?? operator returns the right-hand value only when the left-hand one is null or undefined. We will look at it in detail in the next lesson.

Typing a ten-line function into the REPL line by line is awkward: if you get the third one wrong, you cannot go back. That is what .editor is for.

Press Ctrl+D to leave editor mode and evaluate the whole block at once. Then try it out:

Once the function works, .save reports/exploration.js stores the session and you have the code ready to paste into src/.

Ctrl+D finishes, Ctrl+C cancels. Mixing them up loses the whole block. On Windows, if Ctrl+D does not respond, try Ctrl+Z followed by Enter.

Sometimes you only want an answer, not an interactive session. Node accepts code straight from the command line.

A very practical case: processing a JSON file from the terminal without installing any extra tooling.

Node knows how to read a .json with require and hand it back already converted into an object. This trick will solve a lot of quick checks for you from Module 3 onwards, when the file data/events.json becomes the real source of the catalog.

You can also feed the REPL through a pipe, although in that case you will not see the > prompt:

Node's REPL supports top-level await, something you cannot do in a CommonJS .js file. That makes it an excellent test bench for asynchronous code (the subject of Module 2).

If you do not use await, the REPL shows you the promise, not its value:

Shortly afterwards the REPL prints the resolved result on its own, which can look like it "appeared out of nowhere". Do not be alarmed: that is the REPL reporting that the promise settled.

Try the first one yourself:

In the first case, JavaScript reads { as the start of a block and title: as a label; the value of the block is its last expression. With parentheses, you force it to be read as an object literal.

The REPL is a tool for exploring, not for building. This table sums up the right choice:

The rule is simple: if you are going to need the result more than once, it does not belong in the REPL. Prototype in the REPL, save with .save, refine in a file.

And about the debugger: the REPL tells you what an isolated expression does; the debugger lets you stop a running program at any line you like and inspect all of its variables at that instant. They complement each other, they are not alternatives.

Mistake 1: being alarmed by the undefined after every declaration. It is the value of the expression, not a failure. const x = 5 produces no value.

Mistake 2: typing { key: value } expecting an object. The REPL reads it as a block. Wrap it in parentheses.

Mistake 3: getting stuck at the ... prompt. You have left a brace, a parenthesis or a quote unclosed. Get out with .break or Ctrl+C.

Mistake 4: confusing .load with require. .load evaluates the text in your session (you see every variable). require returns only what was exported.

Mistake 5: using .clear by accident. It wipes every variable in the session. If you have invested time loading and transforming data, run .save first.

Mistake 6: sorting with sort and ruining the original array. sort, reverse, splice, push and pop all mutate the array. Copy it with [...array] before sorting.

Tip 1: use _ freely. Chaining _ is the fastest way to refine a calculation step by step.

Tip 2: .save when an exploration has been productive. Saving the session into reports/ spares you from reconstructing the reasoning tomorrow.

Tip 3: Tab is your documentation. Before searching the internet for which methods path has, type path. and press Tab twice.

Tip 4: keep a REPL open in a terminal tab. With the catalog loaded, answering a question takes seconds.

Open the REPL, load src/catalog-data.js with .load and answer these questions using a single expression each time. Write down the command and the result.

1. How many sessions are there in the catalog in total?
2. What is the average ticket price, in euros?
3. Which events have more than two sessions?
4. How many tickets remain unsold across the whole catalog?
5. Which is the most expensive session, and which event does it belong to?

Using .editor, write a function sessionsPerMonth(events) that returns an object where each key is the month in YYYY-MM format and the value is the number of sessions scheduled that month. Try it out with the catalog and show the result with console.table. Then save the session to reports/exploration-months.js with .save.

Hint: session.dateTime is an ISO string such as '2026-10-03T20:00:00', so the month can be extracted with slice(0, 7).

Without opening the REPL, write the node -e or node -p commands that solve the following:

1. Print the major version of the installed Node (just the number, for example 24).
2. Print how many milliseconds are left from now until the Concierto de Otono (2026-10-03T20:00:00).
3. Convert 4200 cents into the string '42.00'.
4. Check whether the reports folder exists in the project (print true or false).

Solution 1

A more readable alternative, in two steps with _:

(17,800 cents across 7 sessions = 2,542.86 cents, that is 25.43 EUR.)

Here sort on the result of flatMap is safe: that array is new, it is not the original.

Solution 2

Ctrl+D and try it out:

Bear in mind that .save stores the whole session, including the lines that failed. Review the file before reusing it.

Solution 3

In point 2, subtracting two Date objects automatically converts them to milliseconds since the epoch and returns the difference. If you prefer days:

The REPL is Node.js's laboratory: an environment where trying an idea costs nothing. You have learned to start it with node, to interpret the undefined after declarations, to chain calculations with _, to move around with Tab and the history, and to handle the dot commands — .help, .editor, .save, .load, .break, .clear, .exit.

You have applied it to Escena Viva by creating src/catalog-data.js and loading it with .load to explore live: flattening sessions with flatMap, calculating accumulated revenue with reduce, finding the most expensive session with sort, or discovering that there are 1,189 tickets still to sell. You have also seen node -e and node -p for checks from the terminal, and the quirks that trip people up at first: object literals that need parentheses, pending promises and top-level await.

And above all you are clear about the boundary: the REPL is for exploring; whatever has to be repeated goes into a file, and whatever has to be guaranteed goes into a test.

Along the way, some modern JavaScript tools slipped in almost by stealth: flatMap, the spread operator ..., nullish coalescing ??, arrow functions and destructuring. In the next lesson, Modern JavaScript for Node.js, we will study them one by one and without rushing, always while solving a real problem in the Escena Viva catalog. It is the refresher that will underpin every line of code you write from here to the end of the course.