Nie można znaleźć modułu: Naprawianie problemów z importami w Express i parametrami tras

Rozwiązywanie problemów w API pogodowego typu TypeScript Express często uczy więcej o tym, jak składa się backend w Node, niż jakikolwiek inny abstrakcyjny przewodnik po REST.

Błąd

Po podziale projektu na trasy i kontrolery serwer nie działał z następującym błędem:

Cannot find module '../controllers/weatherController'

Taki komunikat jest powszechny, gdy backend znajduje się w kilku plikach. Express importuje weatherController, a środowisko wykonywania nie potrafi odnaleźć tej ścieżki modułu.

Co sprawdzić

Rozwiązywaj problemy w określonej kolejności, zamiast zgadywać.

Czy plik istnieje? W katalogu src/ powinny znajdować się następujące elementy:

src/
├── controllers/
│   └── weatherController.ts

Czy nazwa folderu jest dokładnie taka sama? Lepiej używać controllers zamiast controller lub Controllers. Na systemach plików wrażliwych na wielkość liter ma znaczenie zarówno liczba, jak i wielkość liter.

Czy nazwa pliku jest dokładnie taka sama? Oczekuje się pliku weatherController.ts, a nie WeatherController.ts, weathercontroller.ts ani weather-controller.ts. Mechanizm rozwiązywania modułów w TypeScript traktuje je jako różne cele.

Czy ścieżka importu jest poprawna? W pliku weatherRoutes.ts importy i powiązania tras wyglądają następująco:

import { Router } from "express";
import { getWeather } from "../controllers/weatherController";

const router = Router();router.get("/:city", getWeather);export default router;

Czy kontroler rzeczywiście eksportuje funkcję? Częstym błędem jest pisanie obsługi bez słowa export, przez co import tras nie ma czego powiązać.

import { Request, Response } from "express";

export const getWeather = (req: Request, res: Response): void => {
  const { city } = req.params;  res.json({
    city,
    temperature: 29,
    condition: "Cloudy",
    humidity: 82,
  });
};

Dodanie słowa export przed funkcją getWeather przywróciło poprawne działanie serwera. Jedno słowo kluczowe, jeden rozwiązany błąd.

Co obejmuje dotychczasowy projekt

W tym etapie usługa pogodowa już zawiera kilka elementów w formacie produkcyjnym:

• Toolchain TypeScript dla repozytorium
• Działający proces Express HTTP
• Odrębne katalogi zamiast jednego mega-pliku
• Routerzy URL połączone z obsługą żądań
• Modyuły obsługi logiki żądań
• Parametry ścieżek, takie jak :city
• Strukturyzowane dane JSON
• Błąd brakuującego modułu naprawiony poprzez lokalną weryfikację ścieżek i eksportów

Rozumienie parametrów trasy

Wypróbuj trasę za pomocą klienta HTTP, takiego jak Postman:

GET http://localhost:3000/weather/bangalore
GET http://localhost:3000/weather/mumbai
GET http://localhost:3000/weather/chennai

Każda odpowiedź zmienia pole city. Struktura pozostaje niezmienna: temperature, condition oraz humidity nadal są obecne. Ciąg znaków przedstawiający miasto pochodzi z segmentu ścieżki po /weather/ i jest dostępny jako req.params.city. W tym właśnie polega sens parametru trasy – jedna definicja trasy, ale wiele wartości może być podstawionych przy każdej prośbie.

Następne wyzwanie: podstawowa weryfikacja

Prośba taka jak poniżej nadal powoduje sukces przy użyciu danych symulowanych:

GET /weather/123

i zwraca coś w rodzaju:

{
  "city": "123",
  "temperature": 29,
  "condition": "Cloudy",
  "humidity": 82
}

Nazwa miasta nie powinna składać się wyłącznie z cyfr. Należy odrzucić takie przypadki zamiast traktować je jako ważne dane pogodowe.

Przetestuj parametr miasta za pomocą wyrażenia /^\d+$/. W przypadku dokładnego dopasowania zwróć błąd 400 Bad Request, zamiast symulowanych danych pogodowych:

res.status(400).json({
  error: "City name must contain letters.",
});

w przeciwnym razie zwróć normalny pakiet danych pogodowych. Wdrożenie sprawdzenia przed wyszukiwaniem gotowej odpowiedzi sprawia, że zasada jest lepiej przestrzegana niż przy wklejeniu gotowego fragmentu kodu.

Szybka weryfikacja wiedzy

Krótki test samokontrolny potwierdza zrozumienie zagadnień, a nie tylko udane skompilowanie kodu:

1. W jaki sposób GET /weather/:city różni się od GET /weather?city=bangalore? Segmenty ścieżki wykorzystują wymagane parametry trasy wbudowane w wzór URL. Wartości po ? to parametry zapytania i są opcjonalne. Preferuj parametry trasy, gdy wartość identyfikuje zasób; preferuj parametry zapytania do filtrowania i włączania/wyłączania funkcji.

2. Dlaczego używać res.status(400).json() ZAMIAST po prostu res.json()? Samo res.json() używa domyślnego kodu 200 OK. Nieprawidłowe dane wymagają kodu statusu wskazującego na błąd, a nie tylko ciągu znaków z informacją o błędzie w ciele odpowiedzi. Klienci polegają na tym kodzie.

3. Która warstwa odpowiada za reguły biznesowe — router, kontroler czy gdzie indziej? Reguły należy umieszczać w kontrolerach. Routerzy jedynie łączą metodę HTTP i ścieżkę z odpowiednim obsługiwaczem. Walidacja oraz wywołania zewnętrzne odbywają się najpierw w kontrolerze, a następnie przenoszą się do modułu usług w miarę rozwoju aplikacji.

4. Co zawiera req.params.city dla GET /weather/mumbai? Ciąg znaków "mumbai", dokładnie tak jak został wpisany w ścieżce.

Co będzie dalej

Symulowane warunki pogodowe już spełniły swoją funkcję. Kolejnym elementem jest API z rzeczywistymi danymi pogodowymi, co oznacza:

• Wywoływanie zewnętrznego API HTTP
• Zmienne środowiskowe (.env), dzięki którym klucze nigdy nie są hardkodowane w kodzie źródłowym
• Używanie fetch lub axios do wysyłania żądań
• Czyste radzenie sobie z czasem wygaśnięcia połączenia i błędami po stronie źródła
• Katalog z usługami, dzięki któremu kontrolery nie są odpowiedzialne za obsługę klienta HTTP

Żądanie ma teraz dodatkową warstwę:

Browser/Postman
      │
      ▼
   Routes
      │
      ▼
 Controllers
      │
      ▼
  Services
      │
      ▼
Weather API (external)

Taka struktura warstwowa jest typowa dla wielu aplikacji Express w produkcji. Budowanie ich stopniowo umożliwia łatwe cofnięcie do poprzedniego stanu w przypadku awarii integracji z rzeczywistymi danymi, zamiast gromadzenia wszystkich funkcji w jednym pliku.

Literatura pokrewna

• Identyfikacja vs Kształtowanie: Wybór Parametrów Trasy lub Stringów Zapytania w Express — Dowiedz się, kiedy wartość powinna znajdować się w parametrze trasy Express, a kiedy w stringu zapytania, jak odczytywać req.params i req.query oraz jak bezpiecznie obsługiwać wartości domyślne i typy danych.
• Balansowanie Generowaniem CRUD Prisma z Uważną Kontrolą Tras — Poznaj, jak generowanie routerów CRUD Prisma oparte na schematach może eliminować powtarzalne fragmenty kodu, zachowując jednocześnie decyzje dotyczące zaufania, zakresu działania i dostępu w kodzie aplikacji.