🟢 C1 · Setup: npm init, express, nodemon

C1 · Setup: npm init, express, nodemon: Setting up an Express project is like **renting an empty shop**: while Spring Boot's "starter" (Chapter B1) hands you a fully furnished ki

Setting up an Express project is like **renting an empty shop**: while Spring Boot's "starter" (Chapter B1) hands you a fully furnished kitchen, Express only hands you the key — you build the counter, the stove, the sign yourself. `npm init` opens an empty contract (package.json), `npm install express` adds one small library (routing + HTTP helpers), the rest (validation, ORM, logging) is your choice. So why does Spring bring everything in one line while Express starts this "bare"? Because the Node ecosystem's philosophy is **un-opinionated** — it does not impose, you decide what you need; for a small service this is fast, for a large team it demands discipline (everyone might pick a different validation library). In Java the closest equivalent is setting up a bare Servlet project — Spring Boot automates that for you, Express does not. For a tester the outcome is the same: if setup is broken there is no server to test; the first smoke test is still "does the app start without error and listen on a port?"

The First Server: Up in 5 Lines

**🐞 Defect Birth — if `app.listen(...)` is forgotten** **Code:** `app.get(...)` was written, the route is defined, but the file has no `app.listen(PORT, ...)` line at the end. **What happens:** `node index.js` runs, the script ends without error, the terminal silently returns to the prompt — there is NO error message. Because no port is listening, `curl http://localhost:3000/api/v1/bugs` returns `ECONNREFUSED`. **Why sneaky:** there is no syntax error, the route is written correctly, parsing passes cleanly. There is not even a stack trace — just "nothing happens". A beginner developer may assume "the server crashed" and hunt for bugs in the route code for hours. **Where the tester catches it:** on automation's very first request, getting a connection refusal (`ECONNREFUSED`) — this is the root of the "cannot reach the server at all" error category in GROUP J.

🎬 From an Empty Shop to a Listening Server

`npm init -y` opened an empty package.json — there is not a single line of server code yet.

`npm install express` — one small library was added, bringing routing + HTTP helpers.

`app.get('/api/v1/bugs', ...)` — a path was defined, but this is ONLY a definition, the server is not listening on any port yet.

Without calling `app.listen(PORT, ...)` an Express app is not considered "alive" — without this line, even defined routes stay unreachable.

The lesson — `node index.js` ending without error does not mean "it works"; the tester wants the first proof from a real request (`curl`/Postman).

From an Empty Folder to the First Response

Create an empty package.json with npm init -y, add the library with npm install express.

Define the first path with app.get('/api/v1/bugs', ...) — this does not start the server yet.

Without calling app.listen(PORT, ...) no request can ever reach the server.

Order the steps to bring up an Express API from scratch.