Konfigurera tsconfig för Node-backendprojekt
Finjustera kompilatoralternativ, modulupplösning och sökvägsalias för en robust TypeScript-konfiguration på serversidan.
Konfigurera tsconfig för Node-backendprojekt är en gratis lektion i Bootcamp i backendutveckling med Node.js på CoddyKit. Detta är lektion 2 av 4. Ni kan läsa hela lektionen gratis nedan och sedan öva praktiskt i webbläsaren med en inbyggd kodredigerare och en AI-handledare som är tillgänglig dygnet runt. Den ingår i lärvägen för Bootcamp i backendutveckling med Node.js, och Era framsteg synkroniseras mellan webben och CoddyKit-appen. Kursen i Bootcamp i backendutveckling med Node.js innehåller totalt 4 lektioner.
Varför tsconfig är viktigt på servern
När ni kör TypeScript i ett Node.js-backendprojekt är tsconfig.json den enda källan till sanning som styr hur koden typkontrolleras och kompileras till JavaScript.
- compilerOptions finjusterar utdata, strikthet och modulsystem.
- include / exclude avgör vilka filer som ingår i projektet.
En backendkonfiguration skiljer sig från en frontendkonfiguration: det finns ingen DOM, ingen bundler och Node laddar den genererade JavaScript-koden direkt. Med rätt inställningar undviker ni subtila kraschfel vid körning och trasiga importer.
{
"compilerOptions": {
"target": "ES2022",
"module": "NodeNext",
"outDir": "dist",
"rootDir": "src",
"strict": true
},
"include": ["src/**/*"]
}Välj rätt target
Alternativet target styr vilken JavaScript-version kompilatorn genererar. I ett backendprojekt begränsas ni inte av gamla webbläsare, utan bara av er Node.js-runtime.
- Node 18 stöder upp till ES2022; Node 20+ stöder ES2023.
- En modern
targetinnebär att funktioner som top-levelawait, klassfält ochArray.at()kompileras till inbyggd kod i stället för omfattande polyfills.
Anpassa target efter den lägsta Node-version ni distribuerar till. Om ni anger ett för högt värde kan kompilatorn generera syntax som er runtime inte kan tolka.
// Works natively when target is ES2022 on Node 18+
const nums = [10, 20, 30];
console.log(nums.at(-1)); // 30
class Cache {
store = new Map(); // class field
set(k, v) { this.store.set(k, v); return this; }
}
console.log(new Cache().set("a", 1).store.get("a")); // 1module och moduleResolution
Dessa två alternativ avgör hur import- och require-satser genereras och löses upp.
- module: vilken typ av moduls syntax kompilatorn genererar.
- moduleResolution: hur TypeScript hittar filerna bakom varje importsökväg.
För moderna Node-backendprojekt är "module": "NodeNext" tillsammans med "moduleResolution": "NodeNext" den rekommenderade kombinationen. Den lär TypeScript att följa Nodes faktiska regler för upplösning, inklusive fältet type i package.json och skillnaden mellan CommonJS och ESM.
{
"compilerOptions": {
"module": "NodeNext",
"moduleResolution": "NodeNext"
}
}Välj mellan CommonJS och ESM
Det viktigaste beslutet för ett Node-backendprojekt är modulsystemet. Det styrs av fältet type i package.json, inte enbart av tsconfig.
"type": "commonjs"(eller utelämnat): filer använderrequire/module.exports."type": "module": filer är ESM och använderimport/export.
Med ESM får ni top-level await och en enhetlig importsytax, men ni måste skriva explicita filändelser i relativa importer. Med CommonJS får ni bredare kompatibilitet med äldre bibliotek. Välj ESM för nya projekt, såvida inte ett beroende kräver CommonJS.
{
"name": "my-api",
"type": "module",
"main": "dist/index.js"
}ESM kräver filändelser
Det här ställer till problem för nästan alla som går över till ESM. När module är NodeNext och paketet har "type": "module" måste relativa importer i källkoden innehålla filändelsen .js, även om filen på disken slutar på .ts.
TypeScript skriver inte om importsökvägar, så sökvägen ni anger är exakt den som Node får vid körning. Ni skriver .js eftersom det är den fil som finns efter kompileringen.
// src/user.service.ts
export function findUser(id) {
return { id, name: "Ada" };
}
// src/index.ts -- note the .js extension on a .ts file
import { findUser } from "./user.service.js";
console.log(findUser(7));Aktivera strict-läget
"strict": true är det mest värdefulla alternativet för tillförlitlighet i backend. Det är ett paraplyalternativ som aktiverar en hel grupp kontroller samtidigt.
- strictNullChecks:
nullochundefinedkan inte längre tilldelas överallt, vilket fångar buggar med saknade värden. - noImplicitAny: varje värde måste ha en känd eller härledbar typ.
- strictFunctionTypes, strictBindCallApply med flera.
På en server förhindrar dessa kontroller hela klasser av produktionskrascher, till exempel att en egenskap läses från ett objekt som kan vara undefined.
function getPort(env) {
// With strictNullChecks, env.PORT is string | undefined
const raw = env.PORT;
const port = raw ? Number(raw) : 3000;
return port;
}
console.log(getPort({ PORT: "8081" })); // 8081
console.log(getPort({})); // 3000outDir, rootDir och bygglayouten
De här alternativen håller den kompilerade utdatafilen tydligt separerad från källkoden.
- rootDir: basmappen för dina indatafiler, vanligtvis
src. - outDir: där genererad JavaScript hamnar, vanligtvis
dist.
Om du anger rootDir garanteras att katalogstrukturen under src speglas exakt under dist. Utan det här alternativet härleder TypeScript roten från dina filer, och en överbliven fil utanför src kan förskjuta hela utdatastrukturen och bryta sökvägen till main.
{
"compilerOptions": {
"rootDir": "src",
"outDir": "dist",
"sourceMap": true,
"declaration": false
},
"include": ["src/**/*"],
"exclude": ["node_modules", "dist"]
}Sökvägsalias med baseUrl och paths
Djupa relativa importer som ../../../config/db är sköra. Med sökvägsalias kan du skriva stabila och lättlästa specifikationer.
- baseUrl: katalogen som relativa importer utgår från när de löses.
- paths: en mappning från aliasmönster till riktiga mappar.
En vanlig konvention är att mappa @/* till src/*, så att alla moduler kan importera från @/services/user.service.js oavsett hur djupt de ligger.
{
"compilerOptions": {
"baseUrl": ".",
"paths": {
"@/*": ["src/*"]
}
}
}Alias finns inte vid körning
Här är den viktiga fallgropen: paths påverkar endast typkontrollen. TypeScript-kompilatorn skriver inte om @/services/user.service.js till en riktig relativ sökväg i den genererade JavaScript-koden.
Därför kommer Node att misslyckas vid körning med ett fel om att modulen inte hittas, om du inte överbryggar skillnaden. Vanliga lösningar är:
- En resolver vid körning, till exempel
tsconfig-paths(CommonJS), eller en loader. - En bundler som
tsupelleresbuildsom bäddar in aliasen. - Ett steg efter bygget som skriver om sökvägarna.
Kom alltid ihåg: tsconfig beskriver typer; körmiljön behöver en egen plan för alias.
Node-typer och snabbare byggen
För att använda globala objekt som process, Buffer och modulen fs med fullständig typning installerar du @types/node och låter TypeScript läsa in dem.
- types: begränsar vilka globala typpaket som inkluderas (till exempel endast
["node"]). - skipLibCheck: hoppar över typkontrollen av
.d.ts-filer i beroenden, vilket kan minska byggtiden avsevärt. - esModuleInterop: låter dig skriva
import express from "express"för CommonJS-standardexporter.
{
"compilerOptions": {
"types": ["node"],
"esModuleInterop": true,
"skipLibCheck": true,
"forceConsistentCasingInFileNames": true,
"resolveJsonModule": true
}
}En komplett tsconfig för en backend
När allt sätts ihop får du här en robust utgångspunkt för en modern ESM-backend i Node.js. Den kompilerar src till dist, tillämpar strikt typkontroll och använder Node:s inbyggda upplösning.
Kombinera detta med "type": "module" i package.json och ett byggskript med tsc -p tsconfig.json. Kom ihåg att hantera sökvägsalias vid körning om du aktiverar paths.
{
"compilerOptions": {
"target": "ES2022",
"module": "NodeNext",
"moduleResolution": "NodeNext",
"rootDir": "src",
"outDir": "dist",
"strict": true,
"esModuleInterop": true,
"skipLibCheck": true,
"forceConsistentCasingInFileNames": true,
"resolveJsonModule": true,
"sourceMap": true,
"types": ["node"],
"baseUrl": ".",
"paths": { "@/*": ["src/*"] }
},
"include": ["src/**/*"],
"exclude": ["node_modules", "dist"]
}Snabbkontroll
Testa din förståelse av sökvägsalias i ett Node-backendbygge.
Sammanfattning
Nu vet du hur du konfigurerar tsconfig.json för ett serverbaserat TypeScript-projekt.
- target: matcha den lägsta Node-versionen som stöds (ES2022 för Node 18+).
- module / moduleResolution: använd
NodeNextför korrekt Node-upplösning. - Fältet type i package.json styr CommonJS kontra ESM; relativa ESM-importer behöver filändelsen
.js. - strict: aktivera det för att upptäcka fel med null och any före produktion.
- rootDir / outDir: behåll en ren bygglayout från
srctilldist. - paths: utmärkt för läsbarhet, men alias måste lösas vid körning av en loader eller bundler.
Med de här alternativen rätt inställda får din Node-backend tillförlitlig typsäkerhet och ett förutsägbart bygge.
Lär dig JavaScript med en AI-lärare – gratis
Skriv och kör riktig kod i webbläsaren, få omedelbar hjälp av en AI-lärare dygnet runt och fortsätt där du slutade – på webben eller i appen.
- Kurser
- 22
- Lektioner
- 92
Vanliga frågor
Är lektionen ”Konfigurera tsconfig för Node-backendprojekt” gratis?
Ja – hela texten till ”Konfigurera tsconfig för Node-backendprojekt” kan läsas gratis här på webben. Om Ni vill öva interaktivt med en inbyggd kodredigerare och en AI-handledare som är tillgänglig dygnet runt och låsa upp resten av kursen i Bootcamp i backendutveckling med Node.js, kan Ni uppgradera till CoddyKit PRO. Kursen i Bootcamp i backendutveckling med Node.js innehåller totalt 4 lektioner.
Vad lär jag mig i ”Konfigurera tsconfig för Node-backendprojekt”?
Finjustera kompilatoralternativ, modulupplösning och sökvägsalias för en robust TypeScript-konfiguration på serversidan. Ni övar på Bootcamp i backendutveckling med Node.js med praktisk kod som körs direkt i webbläsaren, medan en AI-handledare som är tillgänglig dygnet runt svarar på Era frågor under lektionen.
Behöver jag någon erfarenhet för att börja lära mig Bootcamp i backendutveckling med Node.js?
Du behöver inga förkunskaper. Utbildningen i Bootcamp i backendutveckling med Node.js på CoddyKit är upplagd för allt från nybörjare till avancerade elever, så att du kan börja här eller från början och gå fram i din egen takt. Detta är lektion 2 av 4.
Hur lång tid tar lektionen ”Konfigurera tsconfig för Node-backendprojekt”?
De flesta CoddyKit-lektioner tar cirka 5–10 minuter. Varje lektion är kort och interaktiv, så att du gör stadiga framsteg och kan fortsätta precis där du slutade – på webben eller i appen.
Kan jag skriva och köra kod i den här Bootcamp i backendutveckling med Node.js-lektionen?
Ja. Varje Bootcamp i backendutveckling med Node.js-lektion innehåller en inbyggd kodredigerare, så att du kan skriva och köra riktig kod direkt i webbläsaren och få omedelbar AI-feedback – utan lokal installation.
Alla lektioner i den här kursen
- Migrera från CommonJS till inbyggda ES-moduler
- Konfigurera tsconfig för Node-backendprojekt
- Typsäker miljökonfiguration och validering vid körning
- Snabba iterationer med tsx, hot reload och källkartor