"Si un ouvrier veut bien faire son travail, il doit d'abord affûter ses outils." - Confucius, "Les Entretiens de Confucius. Lu Linggong"
Page de garde > La programmation > Pourquoi devriez-vous toujours ajouter la sécurité des types à vos variables d'environnement ?

Pourquoi devriez-vous toujours ajouter la sécurité des types à vos variables d'environnement ?

Publié le 2024-11-08
Parcourir:330

Un peu de contexte

Si vous codez depuis un certain temps, vous connaissez l'importance des variables d'environnement et le rôle qu'elles jouent, ainsi que la difficulté de découvrir un bug provoqué simplement par le fait qu'une foutue variable d'environnement n'a pas été définie dans votre projet. , mdr!

Plus tôt cette année, j'ai travaillé dans une startup basée sur des produits en tant que stagiaire développeur Full Stack. À mesure que le projet grandissait, le nombre de variables environnementales augmentait également. Et tout le monde travaillait sur des fonctionnalités distinctes sur des branches distinctes, nous ne savions donc pas si quelqu'un avait introduit une nouvelle variable d'environnement dans sa branche qui aurait ensuite été fusionnée dans la branche principale. Cela a créé des problèmes lorsque j'ai essayé de déployer mes branches, je savais qu'une nouvelle variable d'environnement avait été ajoutée au projet.

Puis, plus tard, j'ai découvert la pile T3 et elle offrait une solution brillante pour ajouter la sécurité des types aux variables d'environnement. Je ne savais même pas qu’une telle solution existait. Cela fait toujours du bien d’apprendre quelque chose de nouveau quand on s’y attend le moins. La pile T3 utilise le package zod et @t3-oss/env-nextjs pour ajouter une sécurité de type à vos applications, ce que j'ai beaucoup aimé. Après cela, je me suis engagé à toujours sécuriser mes variables d'environnement quoi qu'il arrive.

Si vous démarrez un nouveau projet ou si vous travaillez déjà en équipe, je vous recommande fortement d'ajouter la sécurité des types à vos environnements. En ajoutant simplement cela, vous éviterez vos efforts pour identifier les problèmes dans votre base de code.

Voici comment vous pouvez l'ajouter à votre projet. C'est assez simple.

Qu'est-ce que Zod ?

Zod est une bibliothèque de déclaration et de validation de schéma légère et rapide. Un schéma peut être n'importe quoi, depuis une simple chaîne, un nombre jusqu'à un type d'objet complexe.

Utilisation de base

import {z} from 'zod';

const myBoolean = z.boolean();

myBoolean.parse('true'); // throws error
myBoolean.parse(true) // valid

Création d'un schéma d'objets imbriqués

import { z } from 'zod';

const userSchema = z.object({
    name: z.string(),
    age: z.number(),
    address: z.object({
        house_no: z.string(),
        locality: z.string(),
        city: z.string(),
        state: z.string(),
    })
});

Vous pouvez créer un schéma d'objet simple ou créer un schéma d'objets imbriqués.

Qu'est-ce que t3-oss/env-nextjs ?

C'est simplement un package qui nous aidera à ajouter la sécurité des types aux variables d'environnement

Créons des variables d'environnement de type sécurisé

Créez un fichier env.js à la racine de votre projet.

import {createEnv} from "@t3-oss/env-nextjs"; import {z} from "zod";

export const env = createEnv({
  /*
   * Serverside Environment variables, not available on the client.
   * Will throw if you access these variables on the client.
   */
  server: {
    DB_URI: z.string().url(),
  },
  /*
   * Environment variables available on the client (and server).
   *
   * You'll get type errors if these are not prefixed with NEXT_PUBLIC_.
   */
  client: {
    NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY: z.string().min(1),
  },
  /*
   * Due to how Next.js bundles environment variables on Edge and Client,
   * we need to manually destructure them to make sure all are included in bundle.
   *
   * You'll get type errors if not all variables from `server` & `client` are included here.
   */
  runtimeEnv: {
    DB_URI: process.env.DATABASE_URL,
    NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY:
      process.env.NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY,
  },
});

Usage

import {env} from '@/env';

const CLERK_PUBLISHABLE_KEY = env.NEXT_PUBLISHABLE_KEY;

Si vous passez votre curseur au-dessus de NEXT_PUBLISHABLE_KEY, vous pouvez voir que cette valeur est saisie sous forme de chaîne, cela signifie que nos variables d'environnement sont maintenant saisies.

Nous avons ajouté des variables d'environnement de type sécurisé, mais cela ne s'exécutera pas à chaque moment de construction. nous devons importer notre fichier nouvellement créé dans notre fichier next.config.js. Vous pouvez utiliser le package unjs/jiti pour cela.

Tout d'abord, installez le package jiti à partir de npm.

import { fileURLToPath } from "node:url";
import createJiti from "jiti";
const jiti = createJiti(fileURLToPath(import.meta.url));

jiti("./app/env");

Lorsque vous travaillez avec import.meta.url, il fournit l'URL du fichier dans lequel vous travaillez actuellement. Cependant, il inclut un préfixe file:///, dont vous ne souhaiterez peut-être pas. Pour supprimer ce préfixe, vous pouvez utiliser la fonction fileURLToPath du module node:url.

Par exemple:

import {fileURLToPath} from 'node:url';

// Convert the file URL to a path
const filename = fileURLToPath(import.meta.url);

Maintenant, si vous n'avez pas les variables d'environnement requises, vous verrez une erreur comme celle-ci -

Why you should always add type safety to your environment variables?

Comment ajouter une sécurité de type aux variables d'environnement dans les projets Node.js ?

import dotenv from "dotenv";
import { z } from "zod";

dotenv.config();

const schema = z.object({
  MONGO_URI: z.string(),
  PORT: z.coerce.number(),
  JWT_SECRET: z.string(),
  NODE_ENV: z
    .enum(["development", "production", "test"])
    .default("development"),
});

const parsed = schema.safeParse(process.env);

if (!parsed.success) {
  console.error(
    "❌ Invalid environment variables:",
    JSON.stringify(parsed.error.format(), null, 4)
  );
  process.exit(1);
}

export default parsed.data;

Dans les projets Node.js, nous allons simplement créer un schéma zod et l'analyser par rapport à notre process.env afin de vérifier si toutes les variables d'environnement sont définies ou non.

Usage

import express from "express";
import env from "./env";

const app = express();
const PORT = env.PORT || 5000; // PORT is type safe here....

app.listen(PORT, () => {
console.log("Connected to server on PORT ${PORT}");
connectDB();
});

C'est ainsi que vous ajoutez la sécurité des types à vos variables d'environnement. J'espère que vous avez appris quelque chose de nouveau dans ce tutoriel.

Bon codage !! ?

Déclaration de sortie Cet article est reproduit sur : https://dev.to/shaancodes/why-you-should-always-add-type-safety-to-your-environment-variables-24lk?1 En cas d'infraction, veuillez contacter study_golang @163.com supprimer
Dernier tutoriel Plus>

Clause de non-responsabilité: Toutes les ressources fournies proviennent en partie d'Internet. En cas de violation de vos droits d'auteur ou d'autres droits et intérêts, veuillez expliquer les raisons détaillées et fournir une preuve du droit d'auteur ou des droits et intérêts, puis l'envoyer à l'adresse e-mail : [email protected]. Nous nous en occuperons pour vous dans les plus brefs délais.

Copyright© 2022 湘ICP备2022001581号-3