Impossible de trouver le module : Débogage des imports Express et des paramètres de route

Le débogage d’une API météo TypeScript Express enseigne souvent davantage sur la manière dont un backend Node fonctionne en ensemble qu’un autre tutoriel abstrait sur REST.

L’erreur

Après que le projet ait été divisé en routes et contrôleurs, le serveur a échoué avec :

Cannot find module '../controllers/weatherController'

Ce message est courant lorsque le backend n’est plus contenu dans un seul fichier. Express importe weatherController, mais l’environnement de exécution ne parvient pas à résoudre ce chemin de module.

Que vérifier

Traitez l’erreur dans un ordre précis plutôt que de deviner.

Le fichier existe-t-il ? Dans le répertoire src/, l’arborescence doit inclure :

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

Le nom du dossier correspond-il exactement ? Préférez controllers plutôt que controller ou Controllers. La pluriel et la casse sont importants sur des systèmes de fichiers sensibles à la casse.

Le nom du fichier correspond-il exactement ? On s’attend à weatherController.ts, et non à WeatherController.ts, weathercontroller.ts ou weather-controller.ts. La résolution des modules TypeScript considère ces versions comme des cibles différentes.

Le chemin d’import est-il correct ? Dans weatherRoutes.ts, l’import et la configuration des routes se présentent comme suit :

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

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

Le contrôleur exporte-t-il réellement la fonction ? Une erreur fréquente consiste à écrire le gestionnaire sans export, ce qui fait que l’import de la route n’a rien à lier.

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,
  });
};

L’ajout de export avant getWeather a permis de remettre le serveur en marche. Une seule mot-clé, une erreur résolue.

Ce que le projet couvre jusqu’à présent

À ce stade, le service météorologique intègre déjà plusieurs éléments correspondant à une production réelle :

• Une chaîne d’outils TypeScript pour le répertoire
• Un processus HTTP Express en cours d’exécution
• Des répertoires séparés au lieu d’un seul fichier géant
• Des routeurs URL connectés à des gestionnaires d’actions
• Des modules de gestionnaires pour la logique des requêtes
• Des paramètres de chemin tels que :city
• Des en-têtes JSON structurés
• Une correction des erreurs de module manquant grâce à une vérification locale des chemins et des exportations

Comprendre les paramètres de route

Testez la route depuis un client HTTP comme Postman :

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

Chaque réponse modifie le champ city. La structure reste stable : temperature, condition et humidity restent présents. La chaîne représentant la ville provient du segment de chemin suivant /weather/, accessible via req.params.city. C’est là l’objectif d’un paramètre de route : une définition de route unique, avec plusieurs valeurs substituées pour chaque requête.

Le prochain défi : validation de base

Une requête comme celle-ci fonctionne toujours avec des données fictives :

GET /weather/123

et renvoie quelque chose comme ceci :

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

Le nom d’une ville ne doit pas se composer uniquement de chiffres. Il faut rejeter ce cas au lieu de le considérer comme une entrée météorologique valide.

Vérifiez le paramètre de la ville à l’aide de /^\d+$/. En cas de correspondance parfaite, répondez avec 400 Bad Request au lieu de fournir des données météorologiques fictives :

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

Autrement, retournez le payload météorologique normal. Mettre en œuvre cette vérification avant de rechercher une réponse prédéfinie permet à la règle d’être respectée plus efficacement que l’utilisation d’un extrait déjà prêt.

Vérification rapide des connaissances

Un bref quiz auto-évaluatif permet de confirmer les concepts, et non simplement d’obtenir un résultat par chance lors de la compilation :

1. En quoi GET /weather/:city diffère-t-il de GET /weather?city=bangalore? Les segments de chemin utilisent des paramètres de route obligatoires intégrés au schéma URL. Les valeurs après ? sont des paramètres de requête et restent optionnels. Préférez les paramètres de route lorsque la valeur identifie la ressource ; préférez les paramètres de requête pour les filtres et les options à activer/désactiver.

2. Pourquoi utiliser res.status(400).json() au lieu de simplement res.json()? Seul, res.json() utilise par défaut le statut 200 OK. Les données invalides nécessitent un statut indiquant une erreur, et non seulement une chaîne d’erreur dans le corps de la réponse. Les clients s’appuient sur ce code.

3. Quel niveau gère les règles métier — le routeur, le contrôleur ou ailleurs ? Placer les règles dans les contrôleurs. Les routeurs se contentent de relier la méthode HTTP et l’URL à un gestionnaire. La validation ainsi que les appels externes ont lieu d’abord dans le contrôleur, puis sont transférées vers un module de service à mesure que l’application se développe.

4. Que contient req.params.city pour GET /weather/mumbai? La chaîne "mumbai", telle qu’elle a été saisie dans l’URL.

Que vient ensuite

Le simulateur météorologique a rempli sa fonction. La couche suivante est une API météorologique en temps réel, ce qui implique :

• Appeler une API HTTP externe
• Des variables d’environnement (.env) afin que les clés ne soient jamais codées directement dans le code source
• Utiliser fetch ou axios pour la requête sortante
• Gérer proprement les délais d’attente et les échecs du serveur distant
• Un dossier dédié aux services pour que les contrôleurs ne s’occupent pas directement du client HTTP

Le chemin de la requête bénéficie d’une autre couche :

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

Cette structure en couches correspond à de nombreuses applications Express en production. La construction progressive permet d’avoir un point de restauration clair en cas de défaillance de l’intégration en temps réel, au lieu d’entasser tous les problèmes dans un seul fichier.