8.6 — Checkpoint: dependency detective
Checkpoint. No new concepts today — instead, the professional rite of passage: open an unfamiliar project’s package.json and explain every single line. The file on the right is a realistic Playwright test project — the kind you’ll be handed in week one of the job.
Everything you need is already yours: modules (8.1), npm and semver (8.2), tsc (8.5). Pin each finding to the case board.
{
"name": "shop-e2e",
"version": "2.3.1",
"type": "module",
"scripts": {
"test": "playwright test",
"test:headed": "playwright test --headed",
"report": "playwright show-report",
"typecheck": "tsc --noEmit"
},
"devDependencies": {
"@playwright/test": "^1.44.2",
"typescript": "~5.4.5"
}
}The case: you’ve just joined a team. Someone says “the e2e repo is yours now” and walks away. You open ONE file — this one — and by the end of it you can brief the team on what the project is, how to run it, and what it stands on. Let’s read like a detective: every line is evidence.
The deeper story, with the real names for things — this part is what turns “I saw it” into “I can explain it.”
Real package.json files carry more optional fields you’ll meet: "private": true (never publish this to the registry — standard on test suites), engines (which Node versions are supported), and packageManager (pin npm itself). Same reading skill, more lines of evidence.
The test:headed pattern generalizes: script names with a colon are just a naming convention (test:api, test:smoke) — npm treats them as ordinary names. And scripts can call each other, building small pipelines.
Why trust the file at all? Because npm ci (8.2) enforces it: CI installs exactly what package.json + lockfile declare, or fails loudly. The file isn’t documentation that might lie — it’s configuration that’s executed. That’s why reading it first is reading the truth.
Job note: in interviews, “walk me through this package.json” is a real screening question for QA-automation roles — it tests exactly what you just did: semver literacy, dev-vs-prod judgment, and knowing what each script implies about the workflow.
⌨️ the automated detective
You’ve read a package.json by eye — now write the program that briefs the team automatically, plus a range-reader that decodes semver prefixes.
requirements:
- Create
pkg:nameset to"shop-e2e", ascriptsobject withtest: "playwright test"andreport: "playwright show-report", and adevDependenciesobject with"@playwright/test": "^1.44.2"and"typescript": "~5.4.5". - Write
brief(pkg)returning the one-line summaryshop-e2e · 2 scripts · 2 dev tools— built with a template literal (1.6) and key-counting (4.8), never hard-coded. - Write
allowsMinor(range):trueexactly when the range string starts with"^"(strings are indexable — 1.6). - Print
brief(pkg), thenallowsMinorof the Playwright range, then of the TypeScript range.
when you press RUN, the console must show exactly:
✏️ Quick check 1
This project has devDependencies but NO dependencies field. Does a pure test suite ship code to production? Type yes or no.
✏️ Quick check 2
"typescript": "~5.4.5" — can npm install give this project TypeScript 5.5.0? Type yes or no.
✏️ Quick check 3
Which line makes import/export legal in this project’s files — type the field name.
🗣️ Now teach it back
The full detective brief: explain this package.json to a new teammate — identity, the module switch, what each script does, both version ranges (and why they differ), and what the missing dependencies field proves.
Write it as if your friend is sitting next to you. Saved to your journal — future-you will use these notes to teach others.