Vezérlőpult
4. Fejlesztői környezet: VS Code · Backend elméleti alapok

Backend elméleti alapok · 4. tananyag

Fejlesztői környezet: VS Code

A VS Code-ot már ismered — most viszont backend-fejlesztésre állítjuk be. A cél nem az, hogy szép legyen, hanem hogy kevesebb hibát véts, és gyorsabban megtaláld azokat, amiket mégis vétettél. Végigvesszük, mi az, ami elengedhetetlen, és mi az, ami csak ízlés kérdése.

2 tanóraGyakorlat-központúMunkaterület · beállítások · bővítmények

A fejezet végén tudni fogod

A TELEPÍTÉSSEL NEM FOGLALKOZUNK

A VS Code-ot már használtad a HTML, CSS és JavaScript órákon, tehát a telepítést ismered. Ez a fejezet ott kezdődik, hogy a szerkesztő már a gépeden van — és a lényegre koncentrálunk, megnézzük, hogyan lesz belőle backend-fejlesztő környezet.

1Projekt = mappa

A VS Code mappa-alapú. Ne egyetlen fájlt nyiss meg, hanem mindig a projekt mappáját:

Ez nem esztétikai kérdés. A VS Code szinte minden okos funkciója abból indul ki, hogy tudja, hol van a projekt gyökere:

CSAK EGY FÁJLT NYITOTTÁL MEG ✗ nincs projektnézet, nem látod a szerkezetet ✗ a keresés csak ebben az egy fájlban működik ✗ az IntelliSense nem ismeri a telepített csomagokat ✗ nem érvényesülnek a projekt beállításai ✗ a terminál rossz mappában indul ✗ a hibakereső nem találja a belépési pontot npm ERR! ENOENT … package.json A MAPPÁT NYITOTTAD MEG ✓ látod a teljes fájlszerkezetet ✓ a keresés az egész projektben fut ✓ az IntelliSense ismeri az express, prisma… API-ját ✓ a .vscode beállításai érvényesek ✓ a terminál a projektben indul — nem kell cd ✓ F5-tel azonnal indul a hibakeresés PS C:\projektek\webshop-api> npm run dev
1. ábra — Ugyanaz a projekt, kétféle megnyitással. A jobb oldali az, amit szeretnél.
VESZÉLY — a leggyakoribb kezdő hiba

A C:\projektek mappát nyitod meg, de a projekted a C:\projektek\webshop-api mappában van. Ilyenkor a terminál egy szinttel feljebb indul, és az npm start ezt adja: ENOENT: no such file … package.json.

Mindig azt a mappát nyisd meg, amelyikben a package.json van!

TIPP — a leggyorsabb út

A fájlkezelőben lépj be a projekt mappájába, kattints a címsorba, írd be: cmd (vagy powershell) és Enter — a terminál pontosan ott nyílik meg. Onnan pedig: code .

2A munkaterület

A munkaterület (workspace) az a környezet, amelyben dolgozol: egy vagy több mappa, plusz a hozzájuk tartozó beállítások és ajánlott bővítmények. Kétféle van:

TípusMikor?Hol tárolódik a beállítás?
Egymappás munkaterület Ez a leggyakoribb — egy projekt, egy mappa. Mi ezt használjuk. A projekt .vscode/settings.json fájljában
Többmappás munkaterület Ha egyszerre több különálló mappán dolgozol — például külön backend és frontend mappán Egy .code-workspace fájlban

Önálló munkaterület Node.js backendhez — lépésről lépésre

Így hozol létre egy tiszta, önálló backend-munkaterületet a nulláról:

  1. Mappa és projekt létrehozása (ezt a 3. fejezetből már ismered):
    mkdir webshop-api
    cd webshop-api
    npm init -y
    code .
  2. A .vscode mappa létrehozása a projekt gyökerében. Ide kerülnek azok a beállítások, amelyek ehhez a projekthez tartoznak — és amelyeket a csapat minden tagja megkap.
  3. Beállítások, ajánlott bővítmények és hibakeresési konfiguráció felvétele (a 11. szakaszban ott a teljes, másolható sablon).
  4. Munkaterület megbízhatónak jelölése. Amikor először nyitsz meg egy mappát, a VS Code rákérdez: „Do you trust the authors of the files in this folder?” Ha te hoztad létre a projektet, nyugodtan válaszd a „Yes, I trust the authors” lehetőséget.
FIGYELEM — a Workspace Trust nem formaság

Ha letöltött vagy idegen projektet nyitsz meg, mondj nyugodtan nemet. Korlátozott módban a VS Code nem futtat automatikusan feladatokat, és tiltja azokat a bővítményeket, amelyek kódot futtatnának — ez véd az ellen, hogy egy kártékony projekt puszta megnyitással kárt okozzon.

Két terminál, nem egy

A beépített terminál (Ctrl + `) mindig a megnyitott projektmappában indul. Érdemes rögtön kettőt nyitni (Ctrl + Shift + `):

TerminálMi fut benne?
1.A szerver: npm run dev — ez folyamatosan fut
2.Minden más: npm install …, npx prisma migrate dev, git-parancsok

Ha csak egyet használnál, minden parancshoz le kellene állítanod a szervert. A terminálokat a jobb oldali listában válthatod, vagy a felosztás ikonnal egymás mellé teheted őket.

3A beállítások három szintje

Ugyanaz a beállítás három helyen szerepelhet. Mindig a szűkebb hatókör győz:

1. Felhasználói (User) minden projektedre érvényes — a te ízlésed settings.json a felhasználói profilodban 2. Munkaterület (Workspace) csak erre a projektre — a csapat közös szabályai .vscode/settings.json a projektben 3. Nyelvspecifikus csak adott fájltípusra — pl. csak .md fájlokra "[markdown]": { … } felülírja felülírja A SZŰKEBB GYŐZ Ha a felhasználóiban tabSize: 4, a projektében 2 — akkor 2 lesz.
2. ábra — A projekt beállítása mindig erősebb, mint a személyes ízlésed. Ez szándékos.
SzintMegnyitásIde valóVerziókezelőbe?
Felhasználói Ctrl+,, vagy parancspaletta → Open User Settings (JSON) Betűméret, téma, minimap, ikonkészlet — a te ízlésed ✗
Munkaterület .vscode/settings.json a projektben Formázás, behúzás, sorvég, kizárt mappák — amiben a csapat megegyezik ✓
Nyelvspecifikus Bármelyik fenti fájlban, "[nyelv]" kulccsal Fájltípusonként eltérő szabály (pl. Markdownban ne vágja le a sorvégi szóközöket) a szinttől függ
A DÖNTÉSI SZABÁLY

Tedd fel a kérdést: „Baj lenne, ha a munkatársamnál is így lenne?”

Ha nem baj — sőt, kifejezetten jó —, akkor munkaterület szintre való (pl. mentéskori formázás). Ha csak neked kényelmes — például 18 pontos betűméret —, akkor felhasználói szintre.

Melyik szintre tegyem?

Nyolc beállítás. Döntsd el mindegyikről, hogy a saját beállításaid közé való, vagy a projektbe, amit a csapat is megkap.

1 / 8Helyes: 0
…

4A .vscode mappa

Ez a mappa a projekt gyökerében él, és három fájl fordul elő benne. Mindhárom verziókezelőbe kerül — pontosan az a lényegük, hogy mindenkinél ugyanaz legyen.

FájlMire valóMit ér vele a csapat?
settings.json Projektszintű beállítások Nem kell megbeszélni, ki hány szóközzel húz be — a szerkesztő intézi
extensions.json Ajánlott bővítmények listája Aki megnyitja a projektet, felajánlva kapja a szükséges bővítményeket
launch.json Hibakeresési konfigurációk Mindenki egyetlen F5-tel tud hibát keresni, beállítgatás nélkül
VESZÉLY — mi NE kerüljön a .vscode-ba

Néhány bővítmény (például adatbázis-kliens) ide menti a kapcsolati adatokat, akár jelszóval együtt. Mielőtt feltöltöd a projektet, nyisd meg a settings.json-t, és nézd át: nincs benne jelszó, token, kapcsolati karakterlánc? Ha van, tedd át felhasználói szintre vagy a .env fájlba.

JÓ TUDNI

A .vscode mappa nem kötelező: nélküle is működik minden, csak akkor mindenki a saját beállításaival dolgozik. Egyedül fejlesztve ez még elmegy — csapatban viszont ebből születnek a „nálam más behúzással jelenik meg” típusú, teljesen felesleges viták.

5Elengedhetetlen beállítások ELENGEDHETETLEN

Ez a hét beállítás nem ízlés kérdése: mindegyik konkrét hibát előz meg. Ezek a projektbe (.vscode/settings.json) valók, hogy mindenkinél egyformák legyenek.

Beállítás és értékeMit csinál?Milyen hibát előz meg?
editor.formatOnSave
érték: true
Mentéskor megformázza a fájlt Nem kell a formázással foglalkozni, és a Git-változásokban csak a valódi módosítás látszik
editor.defaultFormatter
érték: "esbenp.prettier-vscode" — a bővítmény azonosítója
Megmondja, melyik bővítmény formázzon Ha több formázó van telepítve, enélkül összeakadnak, vagy a VS Code rákérdez minden mentésnél
editor.codeActionsOnSave
érték: { "source.fixAll.eslint": "explicit" }
Mentéskor lefuttatja az ESLint automatikus javításait Az apró hibák (felesleges pontosvessző, ==) maguktól eltűnnek
files.eol
érték: "\n" (LF) — a másik lehetőség "\r\n" (CRLF)
Egységes sorvéget használ minden fájlban Windows alapból CRLF-et használ. Keveredés esetén a Git minden sort megváltozottnak lát
files.trimTrailingWhitespace
érték: true
Levágja a sorvégi felesleges szóközöket Láthatatlan különbségek a Git-változásokban
files.insertFinalNewline
érték: true
Üres sort tesz a fájl végére Sok eszköz elvárja; enélkül a Git „\ No newline at end of file” megjegyzést ír
search.exclude
érték: { "**/node_modules": true } — a ** tetszőleges mélységű almappa
Kihagyja a keresésből a megadott mappákat Enélkül minden keresés több ezer találatot ad idegen kódból — használhatatlan
VESZÉLY — a CRLF/LF csapda

Ez a leggyakoribb „mi történt?” pillanat vegyes csapatban. Ha valaki CRLF sorvéggel ment, a Git szerint a fájl minden sora megváltozott — pedig csak egy szót írt át. A változáslista olvashatatlanná válik, és a valódi módosítás elvész benne.

Ezért kötelező a "files.eol": "\n" — méghozzá projektszinten, hogy mindenkinél így legyen.

EGY BEÁLLÍTÁS, AMI NEM KÖTELEZŐ, DE NAGYON HASZNOS

"javascript.updateImportsOnFileMove.enabled": "always" — ha átnevezel vagy áthelyezel egy fájlt, a VS Code magától kijavítja az importokat az összes fájlban. Az ESM-ben, ahol a .js kiterjesztés kötelező, ez sok bosszúságtól megkímél.

Állítsd össze a saját settings.json-odat!

Pipáld ki, amit szeretnél — a fájl élőben áll össze lent. Az elengedhetetlenek alapból be vannak jelölve. A végén másold vágólapra, és illeszd be a projekted .vscode/settings.json fájljába.

Elengedhetetlen KÖTELEZŐ
Opcionális — ízlés szerint VÁLASZTHATÓ

6Opcionális beállítások ÍZLÉS SZERINT

Ezek egyike sem befolyásolja a kód működését — kényelmi kérdések. Ezek a felhasználói szintre valók, ne kényszerítsd rá a csapatra.

BeállításMit csinál?Miért szeretheted?
editor.minimap.enabled: falseKikapcsolja a jobb oldali kis térképetTöbb hely a kódnak; hosszú fájlnál sokan hasznosnak tartják — próbáld ki mindkettőt
editor.rulers: [100]Függőleges vonal a 100. karakternélLátod, mikor lesz túl hosszú a sor
editor.stickyScroll.enabledGörgetéskor a tetején tartja a függvény fejlécétHosszú függvényben mindig látod, hol vagy
editor.bracketPairColorization.enabledSzínezi az összetartozó zárójeleketBeágyazott callbackeknél sokat segít (alapból be van kapcsolva)
editor.linkedEditingHTML-tag átnevezésekor a párját is átírjaFrontendes fájloknál kényelmes
files.autoSave: "onFocusChange"Automatikusan ment, ha elkattintaszKényelmes — de --watch mellett gyakori újraindítást okozhat
explorer.compactFolders: falseNem vonja össze az egygyerekes mappákatA src/routes külön sorokban látszik
workbench.startupEditor: "none"Indításkor nem nyit üdvözlő lapotEgyenesen a munkához
terminal.integrated.defaultProfile.windowsMelyik shell induljon WindowsonPowerShell, cmd vagy Git Bash — amelyikhez szoktál
editor.fontLigaturesÖsszevont jelek (pl. =>)Csak akkor működik, ha a betűtípus tudja (Fira Code, Cascadia Code)
FIGYELEM — az automatikus mentés és a --watch

Ha bekapcsolod a files.autoSave-et, és közben fut a npm run dev, a szerver félkész kód mentésekor is újraindul, és hibaüzenetekkel teleírja a terminált. Kezdetben inkább maradj a kézi Ctrl + S-nél: te döntöd el, mikor „kész” egy állapot.

7A négy elengedhetetlen bővítmény

Az előző szakasz beállításai közül több csak akkor működik, ha a hozzá tartozó bővítmény telepítve van. Ez az a négy, ami nélkül ez a fejezet nem működik — mind a négy ingyenes, teljes funkcionalitással, fiók és előfizetés nélkül.

BővítményAzonosítóMiért elengedhetetlen?
ESLint
KÖTELEZŐ
dbaeumer.vscode-eslint Ez jeleníti meg a hibákat gépelés közben, és ez futtatja a mentéskori automatikus javítást. Enélkül a codeActionsOnSave beállítás nem csinál semmit.
Prettier
KÖTELEZŐ
esbenp.prettier-vscode Ez a formázó, amelyre a defaultFormatter hivatkozik. Enélkül a mentéskori formázás nem indul el.
EditorConfig
KÖTELEZŐ
EditorConfig.EditorConfig Beolvassa a projekt .editorconfig fájlját, így a behúzás és a sorvég akkor is egységes, ha valaki más szerkesztőt használ.
DotENV
KÖTELEZŐ
mikestead.dotenv Szintaxiskiemelés a .env fájlokhoz. Apróságnak tűnik, de azonnal látszik tőle, ha elgépeltél egy kulcsot vagy rossz helyre tettél idézőjelet.

Telepítés parancssorból, egy lépésben:

code --install-extension dbaeumer.vscode-eslint
code --install-extension esbenp.prettier-vscode
code --install-extension EditorConfig.EditorConfig
code --install-extension mikestead.dotenv

Az ajánlott bővítmények fájlja

Hogy ne kelljen ezt mindenkinek elmagyarázni, tedd be a projektbe:

// .vscode/extensions.json
{
  "recommendations": [
    "dbaeumer.vscode-eslint",
    "esbenp.prettier-vscode",
    "EditorConfig.EditorConfig",
    "mikestead.dotenv"
  ]
}

Aki ezután megnyitja a projektet, egy értesítést kap: „This workspace has extension recommendations” — és egy kattintással telepítheti mindet.

A TELJES BŐVÍTMÉNY-LISTA A KÖVETKEZŐ FEJEZETBEN

Itt csak azt a négyet vettük, ami ehhez a beállításhoz kell. Az adatbázishoz, az API-tesztelésshez és a napi kényelemhez tartozó bővítményekkel — és azzal, hogyan döntsd el egy bővítményről, hogy megbízható és valóban ingyenes-e — az 5. fejezet foglalkozik.

FIGYELEM — a bővítmény önmagában kevés

Mind az ESLintet, mind a Prettiert a projektbe is telepíteni kell (npm install --save-dev …). A bővítmény csak megjeleníti az eredményt; a szabályokat a projekt csomagja és konfigurációja adja. Enélkül a te gépeden működne, a társadén nem — és parancssorból sem lenne ellenőrizhető. A következő két szakasz pontosan erről szól.

8Prettier a projektben

A Prettier nem vitatkozik a stílusról, hanem eldönti helyetted: idézőjelek, pontosvesszők, sortörések, behúzás. Nincs többé „szerintem így szebb” — és ez pontosan a lényeg.

PRETTIER a KINÉZET — beállítás: .prettierrc • behúzás mérete (tabWidth) • maximális sorhossz (printWidth) • idézőjel: " vagy ' (singleQuote) • pontosvessző a sor végén (semi) • vessző az utolsó elem után (trailingComma) „A kód nem fut másképp tőle.” ESLINT a HELYESSÉG — beállítás: eslint.config.js • nem használt változó (no-unused-vars) • nem létező név (no-undef) • == helyett === (eqeqeq) • async await nélkül (require-await) • sosem futó kód (no-unreachable) „Ettől a kód hibás lehet.”
3. ábra — Két különböző feladat. Ne állítsd be mindkettőt ugyanarra a dologra, mert egymással fognak vitatkozni.

Telepítés a projektbe

npm install --save-dev prettier

.prettierrc a projekt gyökerében:

{
  "semi": true,
  "singleQuote": false,
  "tabWidth": 2,
  "trailingComma": "es5",
  "printWidth": 100,
  "endOfLine": "lf"
}

Mit jelentenek ezek a kulcsok?

Ne másold be vakon — mindegyiknek konkrét, látható hatása van a kódra:

KulcsLehetséges értékekMit csinál?
semi true (alap) · false Kitesz-e pontosvesszőt a sorok végére.
true → const a = 1;
false → const a = 1
singleQuote false (alap) · true Milyen idézőjelet használjon a szövegeknél.
false → kettős idézőjel: "Anna"
true → aposztróf: 'Anna'
Mi false-ra állítjuk, mert a JSON is kettős idézőjelet használ.
tabWidth szám — jellemzően 2 vagy 4 Hány szóköz egy behúzási szint. A JavaScript-világ szokása a 2, mert így a beágyazott kód sem csúszik túl jobbra.
printWidth szám — alapértelmezés 80 Hány karakter után próbáljon sort törni. Nem kemény korlát: a Prettier igyekszik e fölé nem menni, de nem vág ketté szavakat. Mi 100-at használunk, mert a hosszabb változónevek így is kiférnek egy sorba.
trailingComma "all" (alap) · "es5" · "none" Tesz-e vesszőt a felsorolás utolsó eleme után.
"none" → nincs vessző
"es5" → tömbökben és objektumokban igen, függvényparamétereknél nem
"all" → mindenhol, a függvényparamétereknél is
endOfLine "lf" (alap) · "crlf" · "auto" Milyen sorvéget írjon a fájl végére. Ugyanaz a probléma, mint a VS Code files.eol beállításánál — ezért állítjuk itt is "lf"-re, hogy a két eszköz ne dolgozzon egymás ellen.
MIÉRT JÓ A trailingComma?

Elsőre feleslegesnek tűnik vesszőt tenni az utolsó elem után. Az értelme a verziókezelésben mutatkozik meg: ha új elemet adsz a lista végére, záró vessző nélkül két sor változna (az előző sorra oda kell tenni a vesszőt, és jön az új sor). Vesszővel csak egy sor változik — az újonnan hozzáadott. A változáslista így sokkal olvashatóbb.

HONNAN TUDOM, MI AZ ALAPÉRTELMEZÉS?

A .prettierrc-be csak azt kell beleírni, amit meg akarsz változtatni — a többi marad az alapértelmezésen. A fenti fájlban azért szerepel a semi: true is (holott alapból is az), mert így a fájlból egyben látszik, milyen stílusban dolgozik a projekt. A teljes lista a Prettier dokumentációjában, az Options oldalon található.

.prettierignore — ide azok a fájlok kerülnek, amelyeket ne formázzon a Prettier:

node_modules        # idegen kód — nem a mi dolgunk formázni
dist                # generált fájlok — úgyis felülíródnak
package-lock.json   # az npm kezeli, kézzel nem nyúlunk hozzá

És hasznos scriptek a package.json-ba:

"scripts": {
  "format": "prettier --write .",
  "format:check": "prettier --check ."
}
MIÉRT KELL A PROJEKTBE IS, HA A BŐVÍTMÉNY ÚGYIS FORMÁZ?

Három okból:

  • Verzió. A bővítmény a projektben lévő Prettiert használja, ha talál ilyet. Így mindenkinél ugyanaz a verzió fut — különben egy újabb Prettier máshogy tördelné a kódot, és a Git tele lenne ál-változásokkal.
  • Parancssor. Az npm run format:check szerkesztő nélkül is ellenőrzi a projektet — később ezt automatikus ellenőrzésbe is beteheted.
  • Csapat. Aki nem VS Code-ot használ, az is meg tudja formázni a kódot ugyanúgy.

9ESLint a projektben

Amíg a Prettier a kinézetet rendezi, az ESLint a hibákra figyelmeztet — még mielőtt lefuttatnád a kódot.

Beállítás varázslóval

npm init @eslint/config@latest

A varázsló végigkérdez (JavaScript, modulrendszer, Node-környezet), telepíti a szükséges csomagokat, és létrehoz egy eslint.config.js fájlt. Egy egyszerű induló konfiguráció:

import js from "@eslint/js";
import globals from "globals";

export default [
  js.configs.recommended,
  {
    files: ["**/*.js"],
    languageOptions: {
      ecmaVersion: "latest",
      sourceType: "module",
      globals: { ...globals.node },   // process, console… ismert legyen
    },
    rules: {
      "no-unused-vars": "warn",   // figyelmeztetés, nem hiba
      "no-console": "off",       // tanuláshoz kell a console.log
      eqeqeq: "error",            // mindig === legyen
    },
  },
];

Mit jelentenek ezek a mezők?

MezőLehetséges értékekMit csinál?
js.configs.recommended — Az ESLint ajánlott alapszabályai egy csomagban: ezek azok a szabályok, amelyek szinte biztosan valódi hibát jeleznek (pl. no-undef, no-unreachable). Erre építjük rá a saját szabályainkat.
files minták tömbje, pl. ["**/*.js"] Mely fájlokra vonatkozzon ez a blokk. A ** tetszőleges mélységű almappát jelent, a * tetszőleges fájlnevet. Így külön szabályokat adhatsz például a tesztfájloknak.
ecmaVersion "latest" · évszám (pl. 2022) Melyik JavaScript-nyelvváltozatot ismerje. Ha régi értéket adnál meg, az ESLint hibának jelezné az újabb nyelvi elemeket. Nálunk "latest".
sourceType "module" · "commonjs" · "script" Melyik modulrendszert használjuk. Mivel ESM-mel dolgozunk ("type": "module"), ide "module" kell — különben az import szintaktikai hibának látszana.
globals globals.node · globals.browser · saját objektum Milyen globális neveket ismerjen el létezőnek. A globals.node nélkül az ESLint a process és a console nevet is „nem létező változónak” jelezné.
rules "off" · "warn" · "error" Az egyes szabályok szigorúsága — a következő táblázatban részletesen.

A példában szereplő szabályok

SzabályMit jelez?Miért így állítottuk be?
no-unused-vars Létrehoztál egy változót vagy importot, de sehol nem használod "warn" — kísérletezés közben normális, hogy van még nem használt változó; ne piros hibaként villogjon
no-console console.log hívás a kódban "off" — tanuláshoz és fejlesztéshez kell a console.log. Éles projektben szokás "warn"-ra állítani, mert ott naplózó könyvtárat használunk helyette
eqeqeq == használata === helyett "error" — ez valódi hibaforrás: "0" == 0 igaz, de "0" === 0 hamis
TÖBB EZER SZABÁLY LÉTEZIK — MELYIKET HASZNÁLJAM?

Kezdetben elég a js.configs.recommended és néhány saját szabály. Ha egy konkrét szabályt keresel, az ESLint dokumentációjának Rules oldalán mindegyik szerepel példával együtt. A hibaüzenetben mindig ott van a szabály neve — arra rákeresve azonnal megtalálod, mit kifogásol.

Scriptek a package.json-ba

"scripts": {
  "lint": "eslint .",          // ellenőrzés: kiírja a hibákat
  "lint:fix": "eslint . --fix"  // ellenőrzés + ami javítható, azt kijavítja
}
FIGYELEM — a --fix nem mindent javít

Csak azt, ami egyértelműen javítható (például hiányzó pontosvessző vagy == → ===). Egy nem használt változót nem törölhet ki magától, mert nem tudhatja, hogy elfelejtetted használni, vagy csak még nem írtad meg a hozzá tartozó kódot. Ezt a G3-as feladatban ki is próbálod.

FIGYELEM — régi és új konfigurációs formátum

Az ESLint 9-től az eslint.config.js (ún. flat config) a szabvány. Ha az interneten .eslintrc.json vagy .eslintrc.js fájlt látsz, az a régi formátum — az újabb ESLint alapból nem is veszi figyelembe. Ilyenkor a bővítmény némán hallgat, és azt hiszed, hibátlan a kódod.

A három súlyossági szint

ÉrtékMit jelent?Hogyan látszik?
"off"A szabály kikapcsolvaSemmi
"warn"FigyelmeztetésSárga hullámos aláhúzás; a futtatás sikeres marad
"error"HibaPiros aláhúzás; az npm run lint hibakóddal áll le
TANULÁS KÖZBEN

Kezdetben állítsd a no-unused-vars szabályt "warn" szintre. Kísérletezés közben teljesen normális, hogy létrehozol egy változót, amit még nem használsz — ha ez piros hibaként villogna, csak zavarna. A valódi hibákat (eqeqeq) viszont hagyd "error"-on.

10EditorConfig

Az .editorconfig fájl szerkesztőfüggetlen: a VS Code, a WebStorm, a Sublime és sok más szerkesztő is érti. Ez a legalsó közös nevező, ami akkor is működik, ha valaki nem VS Code-ot használ.

# .editorconfig — a projekt gyökerében
root = true

[*]
charset = utf-8
end_of_line = lf
indent_style = space
indent_size = 2
insert_final_newline = true
trim_trailing_whitespace = true

[*.md]
trim_trailing_whitespace = false

Mit jelentenek ezek a kulcsok?

KulcsLehetséges értékekMit csinál?
root true · false „Innen felfelé ne keress tovább.” Enélkül a szülőmappákban lévő .editorconfig fájlok is érvényesülnének — ami meglepetéseket okozhat. A projekt gyökerében mindig true.
[*] fájlminta Melyik fájlokra vonatkozzon az alatta lévő blokk. A * minden fájlt jelent; a [*.md] csak a Markdown-fájlokat.
charset utf-8 · latin1 · … Karakterkódolás. Magyar szövegeknél kötelezően utf-8, különben az ékezetek elromlanak.
end_of_line lf · crlf · cr Sorvég-jelölés. Ugyanaz, mint a VS Code files.eol beállítása — csak ez akkor is működik, ha valaki más szerkesztőt használ.
indent_style space · tab Szóközzel vagy tabulátorral húzzuk-e be a kódot. A JavaScript-világ szokása a szóköz.
indent_size szám Hány szóköz egy behúzási szint. Legyen ugyanaz, mint a Prettier tabWidth értéke — különben a két eszköz egymás ellen dolgozna.
insert_final_newline true · false Üres sor a fájl végén. Sok eszköz elvárja; enélkül a Git „\ No newline at end of file” megjegyzést ír a változáslistába.
trim_trailing_whitespace true · false Levágja-e a sorvégi felesleges szóközöket. Ezek láthatatlanok, de a Git változásként mutatja őket.
MIÉRT KIVÉTEL A MARKDOWN?

Markdownban két sorvégi szóköz sortörést jelent. Ha a szerkesztő levágja őket, szétesik a formázás — ezért kapja a .md fájl a trim_trailing_whitespace = false kivételt. Ez egyben jó példa arra, mikor van értelme fájltípusonként eltérő beállításnak.

11A kész munkaterület-sablon

Itt van egyben minden, amiről eddig szó volt. Ezt a szerkezetet érdemes egyszer felépíteni, és utána minden új projektnél újrahasználni.

webshop-api/ .vscode/ settings.json extensions.json launch.json src/ routes/ controllers/ services/ middlewares/ app.js node_modules/ .env .env.example .editorconfig .gitignore .prettierrc eslint.config.js index.js package.json ← a szerkesztő beállításai (verziókezelőbe kerül) ← a saját kódod, rétegekre bontva ← titkok — SOHA nem kerül verziókezelőbe ← generált — SOHA nem kerül verziókezelőbe ← a .env mintája, üres értékekkel ← ez zárja ki a fenti kettőt
4. ábra — A pirossal jelölt kettőt a .gitignore zárja ki.

.vscode/settings.json

{
  // mentéskor formázzon
  "editor.formatOnSave": true,

  // és a Prettier bővítménnyel tegye (azonosító, nem név!)
  "editor.defaultFormatter": "esbenp.prettier-vscode",

  // mentéskor futtassa le az ESLint javítható javításait is
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": "explicit"
  },

  // LF sorvég — a CRLF/LF keveredés ellen
  "files.eol": "\n",
  "files.trimTrailingWhitespace": true,   // sorvégi szóközök levágása
  "files.insertFinalNewline": true,       // üres sor a fájl végére

  // ezekben a mappákban ne keressen (** = tetszőleges mélységű almappa)
  "search.exclude": {
    "**/node_modules": true,
    "**/dist": true
  },

  // fájl átnevezésekor javítsa az importokat
  "javascript.updateImportsOnFileMove.enabled": "always"
}
ITT SZABAD KOMMENTELNI — MÁSHOL NEM

A VS Code beállításfájljai (settings.json, launch.json, extensions.json) egy engedékenyebb JSON-változatot használnak, amely megengedi a // kommenteket. A package.json-ban és a .prettierrc-ben viszont tilos — ott a komment azonnal szintaktikai hiba.

MIT JELENT AZ "explicit"?

A codeActionsOnSave három értéket fogad el:

  • "explicit" — csak akkor fusson le, amikor te mented (Ctrl+S). Ezt használjuk.
  • "always" — automatikus mentésnél is lefut. Ez félkész kódon is átírná a fájlt, ami zavaró.
  • "never" — soha ne fusson (azaz kikapcsolva).

.gitignore

node_modules/   # több száz MB, bármikor újratelepíthető
.env            # titkok: adatbázis-jelszó, JWT-kulcs
dist/           # generált fájlok — a forrásból újra előállnak
*.log           # naplófájlok (a * tetszőleges fájlnevet jelent)

.env.example

# Ez a minta — ezt MEGOSZTJUK. Az értékek szándékosan üresek.
PORT=3000
DATABASE_URL=
JWT_SECRET=
TIPP — csináld meg egyszer, használd sokszor

Hozz létre egy backend-sablon mappát ezzel a teljes szerkezettel. Új projektnél csak lemásolod, átírod a package.json nevét, és már mehet is az npm install. A fejezet G4-es feladata pontosan ez.

12Hibakeresés

A console.log hasznos, de van egy jobb eszköz: a hibakereső (debugger). Megállítja a programot egy adott sornál, és megmutatja minden változó aktuális értékét — anélkül, hogy egyetlen sort is beleírnál a kódba.

console.logHibakereső
Mit látsz?Amit előre kiírattálMinden változót abban a pillanatban
Kell hozzá kódmódosítás?Igen, és utána törölni is kellNem
Változtathatsz futás közben?NemIgen, átírhatod a változók értékét
Látod, honnan hívták a függvényt?NemIgen — hívási lánc (call stack)

A leggyorsabb út: JavaScript Debug Terminal

  1. Parancspaletta (Ctrl + Shift + P) → Debug: JavaScript Debug Terminal
  2. Ebben a terminálban indítsd a programot: npm run dev
  3. Kész — a töréspontok azonnal működnek, konfiguráció nélkül.

Konfigurációval: .vscode/launch.json

Futtatás és hibakeresés nézet (Ctrl + Shift + D) → create a launch.json file → Node.js:

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "request": "launch",
      "name": "Program indítása",
      "program": "${workspaceFolder}/index.js",
      "skipFiles": ["<node_internals>/**"],
      "console": "integratedTerminal"
    },
    {
      "type": "node",
      "request": "launch",
      "name": "Fejlesztői mód (--watch)",
      "program": "${workspaceFolder}/index.js",
      "runtimeArgs": ["--watch", "--env-file=.env"],
      "skipFiles": ["<node_internals>/**"],
      "console": "integratedTerminal"
    }
  ]
}

Mit jelentenek ezek a mezők?

MezőLehetséges értékekMit csinál?
type "node" · "chrome" · … Milyen hibakeresőt indítson. Nálunk mindig "node".
request "launch" · "attach" Elindítsa a programot (launch), vagy egy már futóhoz csatlakozzon (attach). Nekünk az előbbi kell.
name tetszőleges szöveg Ez a név jelenik meg a hibakeresés-nézet legördülő listájában. Több konfigurációnál ebből tudod, melyiket indítod.
program fájlútvonal Melyik fájlt futtassa. A ${workspaceFolder} a megnyitott projektmappa — így az útvonal minden gépen működik, nem kell beleégetni a C:\… kezdetű saját útvonaladat.
runtimeArgs kapcsolók tömbje Milyen kapcsolókkal induljon maga a Node. Ide kerül például a --watch és az --env-file=.env — ugyanaz, amit a dev scriptben is használunk.
skipFiles fájlminták tömbje Mely fájlokba ne lépjen be lépkedés közben. A <node_internals>/** a Node saját forráskódját jelenti — enélkül időnként abban találnád magad, ami tanulás közben csak összezavar.
console "integratedTerminal" · "internalConsole" · "externalTerminal" Hova írja a program kimenetét. Az "integratedTerminal" a beépített terminált használja — ez azért jó, mert billentyűzet-bemenetet is fogad, míg a belső konzol nem.

A hibakereső használata

1 function atlag(lista) { 2 let osszeg = 0; 3 for (const t of lista) { 4 osszeg += t.jegy; 5 } 6 return osszeg / lista.length; 7 } 8 console.log(atlag(tanulok)); A piros pötty a töréspont — a sorszám mellé kattintva tehető ki. F5 Continue fut a következő töréspontig indítás is F10 Step Over következő sor — ezt használod F11 Step Into belép a hívott függvénybe Shift+F11 Step Out kilép az aktuális függvényből Shift+F5 Stop leállítja a futtatást Jobb gomb a törésponton → feltételes töréspont
5. ábra — A gyakorlatban a F10-et fogod a legtöbbet használni.
PanelMit mutat?
VariablesA helyi és globális változók aktuális értéke
WatchÁltalad megadott kifejezések értéke (pl. lista.length)
Call StackMelyik függvény hívta a másikat — visszafelé az egész lánc
BreakpointsAz összes töréspontod, ki-be kapcsolhatóan
TIPP — feltételes töréspont

Kattints jobb gombbal a törésponton → Edit Breakpoint… → adj meg feltételt, például t.jegy > 5. A program csak akkor áll meg, amikor tényleg érdekes. Egy 1000 elemű cikluson végigkattintani ugyanis reménytelen — feltétellel viszont egy pillanat.

13Billentyűparancsok

MűveletWindows / LinuxmacOS
Parancspaletta — minden funkció innenCtrl+Shift+PCmd+Shift+P
Fájl gyors megnyitásaCtrl+PCmd+P
Terminál ki/beCtrl+`Ctrl+`
Új terminálCtrl+Shift+`Ctrl+Shift+`
Kód formázásaShift+Alt+FShift+Option+F
Sor(ok) kommenteléseCtrl+/Cmd+/
Sor mozgatása fel/leAlt+↑/↓Option+↑/↓
Sor másolása leShift+Alt+↓Shift+Option+↓
Átnevezés mindenholF2F2
Ugrás a definícióhozF12F12
Következő azonos találat kijelöléseCtrl+DCmd+D
Keresés a projektbenCtrl+Shift+FCmd+Shift+F
Hibakeresés indításaF5F5
BeállításokCtrl+,Cmd+,
A KETTŐ, AMI A LEGTÖBBET SPÓROL

F2 — átnevezés mindenhol: átírja a változó vagy függvény nevét az összes hivatkozásnál, a projekt egészében. Kereséssel-cserével ez kockázatos lenne (mi van, ha egy szövegben is szerepel ugyanaz a szó?), az F2 viszont érti a kódot.

F12 — ugrás a definícióhoz: rákattintasz egy függvényhívásra, és odaugrik, ahol megírták. Visszafelé: Alt+←.

Billentyűparancs-gyakorló

Nyolc helyzet. Melyik billentyűkombinációt használnád? (Windows-parancsok.)

1 / 8Helyes: 0
…

A teljes lista: Help → Keyboard Shortcuts Reference (Ctrl+K, majd Ctrl+S). Ne akard mindet megtanulni — válassz hármat hetente, és használd tudatosan.

14Vidd magaddal a beállításaidat

Az iskolai gépen felépíted a környezetedet, otthon pedig kezdheted elölről? Nem kell — két megoldás is van rá.

Profilok AJÁNLOTT

A profil egy külön beállítás- és bővítménykészlet. Készíthetsz egy „Node backend” profilt, és külön egyet a frontendes munkához — így nem zavarnak össze a felesleges bővítmények.

A fájlt felteheted pendrive-ra vagy felhőbe, és bármelyik gépen egy lépésben visszakapod a teljes környezetedet.

Settings Sync OPCIONÁLIS

A VS Code beépített szinkronizálása: a beállításaid, bővítményeid és billentyűparancsaid egy fiókhoz (GitHub vagy Microsoft) kötve automatikusan átkerülnek minden gépedre. Ingyenes, a parancspalettáról kapcsolható be: Settings Sync: Turn On.

FIGYELEM — iskolai gépen

Ha bejelentkezel a Settings Synchez egy közös gépen, ne felejts el kijelentkezni az óra végén. Ilyen esetben inkább a profil-exportot használd: az nem hagy maga után bejelentkezett fiókot.

AMI ÍGY IS UTAZIK A PROJEKTTEL

Ne feledd: a .vscode mappa és a konfigurációs fájlok (.editorconfig, .prettierrc, eslint.config.js) a projekt részei. Ezek verziókezelővel mennek — függetlenül attól, melyik gépen dolgozol.

15Gyakori problémák

TünetOkMegoldás
Mentéskor nem formáz Nincs alapértelmezett formázó, vagy nincs telepítve a Prettier-bővítmény Ellenőrizd az editor.defaultFormatter beállítást; jobb gomb a szerkesztőben → Format Document With… → Configure Default Formatter
A terminál rossz mappában indul Nem a projektmappát nyitottad meg File → Open Folder… arra a mappára, amelyben a package.json van
Nincs kódkiegészítés az express-hez Nincs telepítve a csomag, vagy nem mappát nyitottál meg npm install, majd mappa megnyitása
Két formázó vitatkozik, ugrál a kód Több formázó-bővítmény van telepítve ugyanarra a fájltípusra Állítsd be fájltípusonként az alapértelmezettet, a többit tiltsd le
Az ESLint nem jelez semmit Régi .eslintrc formátum, vagy nem talál konfigurációt Térj át eslint.config.js-re; nézd meg: View → Output → ESLint — ott kiírja, mi a baja
A Gitben minden sor módosítottnak látszik CRLF/LF keveredés "files.eol": "\n" és .editorconfig
A hibakereső nem áll meg a törésponton Nem a hibakeresővel indítottad a programot F5, vagy JavaScript Debug Terminal
Lassú a keresés A node_modules-ban is keres search.exclude beállítása
A bővítmények nem működnek, „Restricted Mode” felirat A munkaterület nincs megbízhatónak jelölve Ha te hoztad létre a projektet: Manage Workspace Trust → Trust
Furcsán viselkedik a szerkesztő Bővítmény-ütközés vagy elakadt folyamat Parancspaletta → Developer: Reload Window
HA SEMMI NEM SEGÍT

A parancspaletta Developer: Reload Window parancsa újratölti a VS Code-ot a projekt bezárása nélkül — a problémák meglepően nagy része ettől megoldódik. Ha nem: Help → Start Extension Bisect felezéssel megkeresi, melyik bővítmény okozza a hibát.

16Feladatok

Elméleti feladatok
F1⭐ alap

Hatókörök. A felhasználói beállításokban "editor.tabSize": 4 szerepel, a projekt .vscode/settings.json fájljában "editor.tabSize": 2. Mekkora lesz a behúzás ebben a projektben? És egy másikban, ahol nincs projektbeállítás? Miért?

F2⭐ alap

Prettier vagy ESLint? Melyik eszköz feladata?

  • a) Egységes idézőjelek   b) Nem használt változó jelzése
  • c) Sorhossz betartása   d) == helyett === megkövetelése
  • e) Behúzás egységesítése   f) Elfelejtett await jelzése
F3⭐⭐ haladó

Melyik szintre? Döntsd el, felhasználói vagy munkaterület szintre tennéd, és indokold:

  • a) 18 pontos betűméret   b) Mentéskori formázás   c) Sötét téma
  • d) files.eol: "\n"   e) A minimap kikapcsolása   f) A node_modules kizárása a keresésből
F4⭐⭐ haladó

A CRLF-eset. Egy munkatársad átírt egyetlen szót egy fájlban, a Git mégis azt mutatja, hogy mind a 140 sor megváltozott. Mi történhetett, és milyen két beállítással előzhető meg? Írd le 3-4 mondatban, miért baj ez a kódellenőrzés (code review) szempontjából.

F5⭐⭐⭐ kihívás

Hibakeresés tervezése. Egy függvény rossz végösszeget ad vissza a kosárra. Írd le lépésről lépésre, hogyan derítenéd ki a hibát debuggerrel: hova tennél töréspontot, mit néznél a Variables panelen, mikor használnál feltételes töréspontot, és mire jó itt a Call Stack?

Gyakorlati feladatok
G1⭐ alap

Beállítások. Használd az 5. szakasz beállítás-építőjét: állítsd össze a saját settings.json-odat, és illeszd be egy projekt .vscode/settings.json fájljába. Készíts képernyőképet a fájlról.

G2⭐⭐ haladó

Formázás élőben. Hozz létre egy szándékosan csúnyán formázott JavaScript-fájlt (rossz behúzás, keveredő idézőjelek, hiányzó pontosvesszők, sorvégi szóközök). Állítsd be a Prettiert a projektben, és mutasd be a mentés előtti és utáni állapotot.

G3⭐⭐ haladó

ESLint. Állíts be ESLintet, majd írj olyan kódot, amely három figyelmeztetést vált ki (pl. nem használt változó, == használata, elgépelt név). Javítsd ki őket, részben az npm run lint:fix paranccsal. Írd le, melyiket javította automatikusan és melyiket nem — és miért.

G4⭐⭐ haladó

Munkaterület-sablon. Készíts egy backend-sablon mappát a 11. szakasz szerinti teljes szerkezettel: üres mappák, de meglévő konfigurációs fájlok (.editorconfig, .prettierrc, eslint.config.js, .gitignore, .env.example, .vscode/settings.json, .vscode/extensions.json, .vscode/launch.json). Ezt fogod használni a következő projektnél.

G5⭐⭐⭐ kihívás

Hibakeresés console.log nélkül. Írj egy függvényt, amely kiszámolja egy számtömb átlagát, de szándékosan hibás (például <= szerepel a < helyett a ciklusban). Keresd meg a hibát kizárólag debuggerrel! Dokumentáld képernyőképekkel, mit láttál a Variables panelen az egyes lépésekben.

G6⭐⭐⭐ kihívás

Profil. Készíts „Node backend” nevű profilt, telepítsd bele a négy elengedhetetlen bővítményt és a saját beállításaidat, majd exportáld (Profiles: Export Profile). Próbáld ki, hogy egy másik gépen (vagy egy másik profilból visszatérve) valóban helyreáll-e a környezet.

17Önellenőrző kvíz

Tíz kérdés. Válassz, és azonnal megtudod, jó volt-e — magyarázattal.

18Összegzés

  1. A VS Code mappa-alapú: mindig azt a mappát nyisd meg, amelyben a package.json van (code .).
  2. A beállítások három szinten élnek, és a szűkebb győz: felhasználói → munkaterület → nyelvspecifikus.
  3. A döntési szabály: „Baj lenne, ha a munkatársamnál is így lenne?” Ha nem — sőt, jó —, akkor a projektbe való.
  4. A .vscode mappa három fájlja (settings.json, extensions.json, launch.json) verziókezelőbe kerül — de előbb nézd át, nincs-e benne jelszó.
  5. Elengedhetetlen beállítások: mentéskori formázás, alapértelmezett formázó, ESLint-javítás mentéskor, files.eol: "\n", sorvégi szóközök levágása, záró üres sor, node_modules kizárása a keresésből.
  6. Négy elengedhetetlen bővítmény: ESLint, Prettier, EditorConfig, DotENV — mind ingyenes, teljes funkcionalitással.
  7. A Prettiert és az ESLintet a projektbe is telepítjük, nem csak bővítményként — így mindenkinél ugyanaz a verzió fut, és parancssorból is ellenőrizhető.
  8. A Prettier a kinézetért, az ESLint a helyességért felel. Ne állítsd be mindkettőt ugyanarra.
  9. A hibakereső többet ér a console.log-nál: minden változót látsz, kódmódosítás nélkül, hívási lánccal együtt.
  10. A környezetedet profil-exporttal vagy Settings Synckel viheted magaddal gépek között.

19Fogalomtár

FogalomJelentés
ParancspalettaCtrl+Shift+P — minden VS Code-funkció kereshető helye
Munkaterület (workspace)Egy vagy több mappa a hozzá tartozó beállításokkal
Workspace TrustMegbízhatósági kérdés a mappa megnyitásakor; korlátozott módban a VS Code nem futtat kódot
.vscode mappaProjektszintű beállítások, ajánlott bővítmények és hibakeresési konfiguráció helye
IntelliSenseKódkiegészítés és típusinformáció
LinterKódellenőrző program — nálunk az ESLint
FormatterKódformázó program — nálunk a Prettier
Flat configAz ESLint 9 óta használt eslint.config.js formátum
EditorConfigSzerkesztőfüggetlen alapformázási szabályok (.editorconfig)
CRLF / LFWindows, illetve Linux/macOS sorvég-jelölése. Keveredésük hamis Git-változásokat okoz
Töréspont (breakpoint)Sor, ahol a hibakereső megállítja a programot
Feltételes töréspontTöréspont, amely csak megadott feltétel teljesülésekor áll meg
Call stackA hívási lánc: melyik függvény honnan hívódott
WatchFigyelt kifejezés a hibakeresőben
launch.jsonHibakeresési konfiguráció
ProfilKülön beállítás- és bővítménykészlet egy munkakörhöz; exportálható
Settings SyncBeállítások szinkronizálása fiókon keresztül több gép között
← Előző tananyag 3. Node.js telepítése és beállítása