Backend elméleti alapok · 4. tananyag
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.
.vscode mappába, és mi belőle a verziókezelőbe;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.
A VS Code mappa-alapú. Ne egyetlen fájlt nyiss meg, hanem mindig a projekt mappáját:
code . — a . az aktuális mappát jelenti.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:
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..
Mindig azt a mappát nyisd meg, amelyikben a package. van!
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 .
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ípus | Mikor? | 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 . 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 . fájlban |
Így hozol létre egy tiszta, önálló backend-munkaterületet a nulláról:
mkdir webshop-api cd webshop-api npm init -y code .
.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.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.
A beépített terminál (Ctrl + `) mindig a megnyitott projektmappában indul. Érdemes rögtön kettőt nyitni (Ctrl + Shift + `):
| Terminál | Mi 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.
Ugyanaz a beállítás három helyen szerepelhet. Mindig a szűkebb hatókör győz:
| Szint | Megnyitás | Ide 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 | . 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 |
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.
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.
.vscode mappaEz 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ájl | Mire való | Mit ér vele a csapat? |
|---|---|---|
settings. |
Projektszintű beállítások | Nem kell megbeszélni, ki hány szóközzel húz be — a szerkesztő intézi |
extensions. |
Ajánlott bővítmények listája | Aki megnyitja a projektet, felajánlva kapja a szükséges bővítményeket |
launch. |
Hibakeresési konfigurációk | Mindenki egyetlen F5-tel tud hibát keresni, beállítgatás nélkül |
.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.-t,
és nézd át: nincs benne jelszó, token, kapcsolati karakterlánc? Ha van, tedd át
felhasználói szintre vagy a . fájlba.
A . 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.
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 (.) valók, hogy mindenkinél
egyformák legyenek.
| Beállítás és értéke | Mit csinál? | Milyen hibát előz meg? |
|---|---|---|
editor.é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.érték: "esbenp. — 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.érték: { "source. |
Mentéskor lefuttatja az ESLint automatikus javításait | Az apró hibák (felesleges pontosvessző, ==) maguktól eltűnnek |
files.é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.é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.é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.é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 |
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. — méghozzá projektszinten,
hogy mindenkinél így legyen.
"javascript. — 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 . kiterjesztés kötelező, ez sok bosszúságtól megkímél.
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
. fájljába.
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ás | Mit csinál? | Miért szeretheted? |
|---|---|---|
editor. | Kikapcsolja a jobb oldali kis térképet | Több hely a kódnak; hosszú fájlnál sokan hasznosnak tartják — próbáld ki mindkettőt |
editor. | Függőleges vonal a 100. karakternél | Látod, mikor lesz túl hosszú a sor |
editor. | Görgetéskor a tetején tartja a függvény fejlécét | Hosszú függvényben mindig látod, hol vagy |
editor. | Színezi az összetartozó zárójeleket | Beágyazott callbackeknél sokat segít (alapból be van kapcsolva) |
editor. | HTML-tag átnevezésekor a párját is átírja | Frontendes fájloknál kényelmes |
files. | Automatikusan ment, ha elkattintasz | Kényelmes — de --watch mellett gyakori újraindítást okozhat |
explorer. | Nem vonja össze az egygyerekes mappákat | A src/routes külön sorokban látszik |
workbench. | Indításkor nem nyit üdvözlő lapot | Egyenesen a munkához |
terminal. | Melyik shell induljon Windowson | PowerShell, cmd vagy Git Bash — amelyikhez szoktál |
editor. | Összevont jelek (pl. =>) | Csak akkor működik, ha a betűtípus tudja (Fira Code, Cascadia Code) |
--watch
Ha bekapcsolod a files.-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.
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ény | Azonosító | Miért elengedhetetlen? |
|---|---|---|
| ESLint KÖTELEZŐ |
dbaeumer. |
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. |
Ez a formázó, amelyre a defaultFormatter hivatkozik. Enélkül a
mentéskori formázás nem indul el. |
| EditorConfig KÖTELEZŐ |
EditorConfig. |
Beolvassa a projekt . 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. |
Szintaxiskiemelés a . 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
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.
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.
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.
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.
npm install --save-dev prettier
. a projekt gyökerében:
{
"semi": true,
"singleQuote": false,
"tabWidth": 2,
"trailingComma": "es5",
"printWidth": 100,
"endOfLine": "lf"
}
Ne másold be vakon — mindegyiknek konkrét, látható hatása van a kódra:
| Kulcs | Lehetséges értékek | Mit 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. 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. |
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.
A .-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ó.
. — 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.-ba:
"scripts": { "format": "prettier --write .", "format:check": "prettier --check ." }
Három okból:
npm run format:check szerkesztő nélkül is
ellenőrzi a projektet — később ezt automatikus ellenőrzésbe is beteheted.Amíg a Prettier a kinézetet rendezi, az ESLint a hibákra figyelmeztet — még mielőtt lefuttatnád a kódot.
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. 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 }, }, ];
| Mező | Lehetséges értékek | Mit csinál? |
|---|---|---|
js. |
— | 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. ["**/*. |
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. · globals. · saját objektum |
Milyen globális neveket ismerjen el létezőnek. A
globals. 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. |
| Szabály | Mit 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. hívás a kódban |
"off" — tanuláshoz és fejlesztéshez kell a
console.. É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 |
Kezdetben elég a js. é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.
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 }
--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.
Az ESLint 9-től az eslint. (ún. flat config)
a szabvány. Ha az interneten . vagy
. 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.
| Érték | Mit jelent? | Hogyan látszik? |
|---|---|---|
"off" | A szabály kikapcsolva | Semmi |
"warn" | Figyelmeztetés | Sárga hullámos aláhúzás; a futtatás sikeres marad |
"error" | Hiba | Piros aláhúzás; az npm run lint hibakóddal áll le |
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.
Az . 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
| Kulcs | Lehetséges értékek | Mit csinál? |
|---|---|---|
root |
true · false |
„Innen felfelé ne keress tovább.” Enélkül a szülőmappákban lévő
. 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 [*. 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.
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. |
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 . 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.
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.
.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"
}
A VS Code beállításfájljai (settings.,
launch., extensions.) egy engedékenyebb
JSON-változatot használnak, amely megengedi a // kommenteket.
A package.-ban és a .-ben viszont
tilos — ott a komment azonnal szintaktikai hiba.
"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=
Hozz létre egy backend-sablon mappát ezzel a teljes szerkezettel. Új
projektnél csak lemásolod, átírod a package. nevét, és már mehet is az
npm install. A fejezet G4-es feladata pontosan ez.
A console. 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. | Hibakereső | |
|---|---|---|
| Mit látsz? | Amit előre kiírattál | Minden változót abban a pillanatban |
| Kell hozzá kódmódosítás? | Igen, és utána törölni is kell | Nem |
| Változtathatsz futás közben? | Nem | Igen, átírhatod a változók értékét |
| Látod, honnan hívták a függvényt? | Nem | Igen — hívási lánc (call stack) |
npm run dev.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"
}
]
}
| Mező | Lehetséges értékek | Mit 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=. — 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. |
| Panel | Mit mutat? |
|---|---|
| Variables | A helyi és globális változók aktuális értéke |
| Watch | Általad megadott kifejezések értéke (pl. lista.) |
| Call Stack | Melyik függvény hívta a másikat — visszafelé az egész lánc |
| Breakpoints | Az összes töréspontod, ki-be kapcsolhatóan |
Kattints jobb gombbal a törésponton → Edit Breakpoint… → adj meg feltételt,
például t.. A program csak akkor áll meg, amikor tényleg érdekes.
Egy 1000 elemű cikluson végigkattintani ugyanis reménytelen — feltétellel viszont egy pillanat.
| Művelet | Windows / Linux | macOS |
|---|---|---|
| Parancspaletta — minden funkció innen | Ctrl+Shift+P | Cmd+Shift+P |
| Fájl gyors megnyitása | Ctrl+P | Cmd+P |
| Terminál ki/be | Ctrl+` | Ctrl+` |
| Új terminál | Ctrl+Shift+` | Ctrl+Shift+` |
| Kód formázása | Shift+Alt+F | Shift+Option+F |
| Sor(ok) kommentelése | Ctrl+/ | Cmd+/ |
| Sor mozgatása fel/le | Alt+↑/↓ | Option+↑/↓ |
| Sor másolása le | Shift+Alt+↓ | Shift+Option+↓ |
| Átnevezés mindenhol | F2 | F2 |
| Ugrás a definícióhoz | F12 | F12 |
| Következő azonos találat kijelölése | Ctrl+D | Cmd+D |
| Keresés a projektben | Ctrl+Shift+F | Cmd+Shift+F |
| Hibakeresés indítása | F5 | F5 |
| Beállítások | Ctrl+, | Cmd+, |
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+←.
Nyolc helyzet. Melyik billentyűkombinációt használnád? (Windows-parancsok.)
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.
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á.
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.
.code-profile fájlA fájlt felteheted pendrive-ra vagy felhőbe, és bármelyik gépen egy lépésben visszakapod a teljes környezetedet.
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.
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.
Ne feledd: a . mappa és a konfigurációs fájlok
(., .,
eslint.) a projekt részei. Ezek verziókezelővel
mennek — függetlenül attól, melyik gépen dolgozol.
| Tünet | Ok | Megoldá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. 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. 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 . formátum, vagy nem talál konfigurációt |
Térj át eslint.-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. és . |
| 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. 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 |
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.
Hatókörök. A felhasználói beállításokban "editor.
szerepel, a projekt . fájljában
"editor.. Mekkora lesz a behúzás ebben a projektben? És egy
másikban, ahol nincs projektbeállítás? Miért?
Prettier vagy ESLint? Melyik eszköz feladata?
== helyett === megköveteléseawait jelzéseMelyik szintre? Döntsd el, felhasználói vagy munkaterület szintre tennéd, és indokold:
files.eol: "\n" e) A minimap kikapcsolása
f) A node_modules kizárása a keresésbőlA 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.
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?
Beállítások. Használd az 5. szakasz
beállítás-építőjét: állítsd össze a saját settings.-odat, és illeszd be
egy projekt . fájljába. Készíts képernyőképet a
fájlról.
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.
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.
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 (., .,
eslint., .,
., .,
., .).
Ezt fogod használni a következő projektnél.
Hibakeresés console. 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.
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.
Tíz kérdés. Válassz, és azonnal megtudod, jó volt-e — magyarázattal.
package.json van (code .)..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ó.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.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.| Fogalom | Jelentés |
|---|---|
| Parancspaletta | Ctrl+Shift+P — minden VS Code-funkció kereshető helye |
| Munkaterület (workspace) | Egy vagy több mappa a hozzá tartozó beállításokkal |
| Workspace Trust | Megbízhatósági kérdés a mappa megnyitásakor; korlátozott módban a VS Code nem futtat kódot |
. mappa | Projektszintű beállítások, ajánlott bővítmények és hibakeresési konfiguráció helye |
| IntelliSense | Kódkiegészítés és típusinformáció |
| Linter | Kódellenőrző program — nálunk az ESLint |
| Formatter | Kódformázó program — nálunk a Prettier |
| Flat config | Az ESLint 9 óta használt eslint. formátum |
| EditorConfig | Szerkesztőfüggetlen alapformázási szabályok (.) |
| CRLF / LF | Windows, 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éspont | Töréspont, amely csak megadott feltétel teljesülésekor áll meg |
| Call stack | A hívási lánc: melyik függvény honnan hívódott |
| Watch | Figyelt kifejezés a hibakeresőben |
launch. | Hibakeresési konfiguráció |
| Profil | Külön beállítás- és bővítménykészlet egy munkakörhöz; exportálható |
| Settings Sync | Beállítások szinkronizálása fiókon keresztül több gép között |