Modulutvidelse: Sømløs Utvidelse av Tredjepartsbibliotekers Typer

            
// For eksempel, hvis du vil utvide 'lodash'-modulen
import 'lodash';

declare module 'lodash' {
  interface LoDashStatic {
    // Legg til nye metoder eller egenskaper her
    myCustomUtility(input: string): string;
  }
}

            

              
                Copy
              
            
          

            
import _ from 'lodash';

const result = _.myCustomUtility('hei fra verden!');
console.log(result); // Utdata: 'hei fra verden!' (forutsatt at implementasjonen din returnerer input)

            

              
                Copy
              
            
          

            
// src/types/date-fns.d.ts

// Importer modulen for å signalisere utvidelse.
// Denne linjen legger ikke til noen kjøretidskode.
import 'date-fns';

declare module 'date-fns' {
  // Vi skal utvide hovedeksporten, som ofte er et navnerom eller et objekt.
  // For date-fns er det vanlig å jobbe direkte med funksjoner, så vi kan
  // trenge å utvide en spesifikk funksjon eller modulens eksportobjekt.
  // La oss anta at vi vil legge til en ny formateringsfunksjon.

  // Vi må finne det rette stedet å utvide. Ofte eksporterer biblioteker
  // et standardobjekt eller et sett med navngitte eksporter. For date-fns kan vi utvide
  // modulens standardeksport hvis den brukes på den måten, eller spesifikke funksjoner.
  // Et vanlig mønster er å utvide selve modulen hvis spesifikke eksporter ikke er direkte tilgjengelige for utvidelse.

  // La oss illustrere utvidelsen av en hypotetisk 'format'-funksjon hvis den var en metode på et Date-objekt.
  // Mer realistisk utvider vi modulen for potensielt å legge til nye funksjoner eller endre eksisterende.

  // For date-fns kan en mer direkte tilnærming være å deklarere en ny funksjon
  // i en deklarasjonsfil som bruker date-fns internt.
  // Men for å demonstrere modulutvidelse ordentlig, la oss late som om date-fns
  // har et global-lignende objekt vi kan utvide.

  // En mer nøyaktig tilnærming for date-fns ville være å legge til en ny funksjonssignatur
  // til modulens kjente eksporter hvis vi skulle endre kjernebibliotekets typer.
  // Siden vi utvider, la oss vise hvordan man legger til en ny navngitt eksport.

  // Dette er et forenklet eksempel som antar at vi vil legge til en `formatEuropeanDate`-funksjon.
  // I virkeligheten eksporterer date-fns funksjoner direkte. Vi kan legge til vår funksjon i modulens eksporter.

  // For å utvide modulen med en ny funksjon, kan vi deklarere en ny type for moduleksporten.
  // Hvis biblioteket vanligvis importeres som `import * as dateFns from 'date-fns';`,
  // ville vi utvidet `DateFns`-navnerommet. Hvis det importeres som `import dateFns from 'date-fns';`,
  // ville vi utvidet standardeksporttypen.

  // For date-fns, som eksporterer funksjoner direkte, ville du vanligvis definere din egen
  // funksjon som bruker date-fns internt. Men hvis bibliotekstrukturen tillot det
  // (f.eks. at den eksporterte et objekt med verktøy), kunne du utvidet det objektet.

  // La oss demonstrere utvidelsen av et hypotetisk verktøyobjekt.
  // Hvis date-fns eksponerte noe som `dateFns.utils.formatDate`, kunne vi gjort:

  // interface DateFnsUtils {
  //   formatEuropeanDate(date: Date): string;
  // }
  // interface DateFns {
  //   utils: DateFnsUtils;
  // }

  // En mer praktisk tilnærming for date-fns er å utnytte `format`-funksjonen og legge til
  // en ny formatstreng eller lage en omslagsfunksjon.
  // La oss vise hvordan man utvider modulen for å legge til et nytt formateringsalternativ for den eksisterende `format`-funksjonen.
  // Dette krever kjennskap til den interne strukturen til `format` og dens aksepterte format-tokens.

  // En vanlig teknikk er å utvide modulen med en ny navngitt eksport, hvis biblioteket støtter det.
  // La oss anta at vi legger til en ny verktøyfunksjon i modulens eksporter.
  // Vi utvider selve modulen for å legge til en ny navngitt eksport.

  // Først, la oss prøve å utvide selve moduleksporten.
  // Hvis date-fns var strukturert som: `export const format = ...; export const parse = ...;`
  // Kan vi ikke legge til direkte til disse. Modulutvidelse fungerer ved å slå sammen deklarasjoner.

  // Den vanligste og korrekte måten å utvide moduler som date-fns på er å
  // bruke modulutvidelse for å deklarere tilleggsfunksjoner eller modifisere
  // eksisterende *hvis* bibliotekets typer tillater det.

  // La oss vurdere et enklere tilfelle: å utvide et bibliotek som eksporterer et objekt.
  // Eksempel: Hvis `libraryX` eksporterer `export default { methodA: () => {} };`
  // `declare module 'libraryX' { interface LibraryXExport { methodB(): void; } }`

  // For date-fns, la oss illustrere ved å legge til en ny funksjon i modulen.
  // Dette gjøres ved å deklarere modulen og deretter legge til et nytt medlem i eksportgrensesnittet.
  // Men date-fns eksporterer funksjoner direkte, ikke et objekt som kan utvides på denne måten.

  // En bedre måte å oppnå dette for date-fns er ved å lage en ny deklarasjonsfil som
  // utvider modulens evner ved å legge til en ny funksjonssignatur.
  // La oss anta at vi utvider modulen for å legge til en ny toppnivåfunksjon.
  // Dette krever forståelse for hvordan modulen er ment å bli utvidet.

  // Hvis vi vil legge til en `formatEuropeanDate`-funksjon:
  // Dette gjøres best ved å definere din egen funksjon og importere date-fns i den.
  // Men for å tvinge frem problemstillingen med modulutvidelse for demonstrasjonens skyld:

  // Vi utvider modulen 'date-fns' for å inkludere en ny funksjonssignatur.
  // Denne tilnærmingen forutsetter at moduleksportene er fleksible nok.
  // Et mer realistisk scenario er å utvide en type som returneres av en funksjon.

  // La oss anta at date-fns har en hovedobjekteksport, og at vi kan legge til den.
  // (Dette er en hypotetisk struktur for demonstrasjon)
  // declare namespace dateFnsNamespace { // Hvis det var et navnerom
  //   function format(date: Date, formatString: string): string;
  //   function formatEuropeanDate(date: Date): string;
  // }

  // For praktisk date-fns-utvidelse: du kan utvide `format`-funksjonens
  // evner ved å deklarere et nytt format-token den forstår.
  // Dette er avansert og avhenger av bibliotekets design.

  // Et enklere, mer vanlig bruksområde: å utvide et biblioteks objektegenskaper.
  // La oss bytte til et mer vanlig eksempel som passer direkte for modulutvidelse.
  // Anta at vi bruker et hypotetisk `apiClient`-bibliotek.
}

            

              
                Copy
              
            
          

            
// Slik kan biblioteket være strukturert internt
export interface AppConfig {
  apiUrl: string;
  timeout: number;
}

export const config: AppConfig = { ... };

            

              
                Copy
              
            
          

            
// src/types/config.d.ts

import 'config'; // Dette signaliserer utvidelse for 'config'-modulen.

declare module 'config' {
  // Vi utvider det eksisterende AppConfig-grensesnittet fra 'config'-modulen.
  interface AppConfig {
    // Legg til vår nye egenskap.
    environment: 'development' | 'staging' | 'production';
    // Legg til en annen egendefinert egenskap.
    featureFlags: Record;
  }
}

            

              
                Copy
              
            
          

            
// src/config.ts

// Vi må importere den opprinnelige konfigurasjonen for å utvide den.
// Hvis 'config' eksporterer `config: AppConfig` direkte, ville vi importert den.
// For dette eksempelet, la oss anta at vi overstyrer eller utvider det eksporterte objektet.

// VIKTIG: Denne filen må fysisk eksistere og bli kompilert.
// Det er ikke bare typedeklarasjoner.

// Importer den opprinnelige konfigurasjonen (dette antar at 'config' eksporterer noe).
// For enkelhets skyld, la oss anta at vi re-eksporterer og legger til egenskaper.
// I et reelt scenario kan du importere det originale konfigurasjonsobjektet og mutere det,
// eller levere et nytt objekt som samsvarer med den utvidede typen.

// La oss anta at den opprinnelige 'config'-modulen eksporterer et objekt vi kan legge til.
// Dette gjøres ofte ved å re-eksportere og legge til egenskaper.

// Dette krever at den opprinnelige modulen er strukturert på en måte som tillater utvidelse.
// Hvis den opprinnelige modulen eksporterer `export const config = { apiUrl: '...', timeout: 5000 };`,
// kan vi ikke legge til det direkte ved kjøretid uten å endre den opprinnelige modulen eller dens import.

// Et vanlig mønster er å ha en initialiseringsfunksjon eller en standardeksport som er et objekt.

// La oss redefinere 'config'-objektet i prosjektet vårt, og sikre at det har de utvidede typene.
// Dette betyr at vårt prosjekts `config.ts` vil levere implementasjonen.

import { AppConfig as OriginalAppConfig } from 'config';

// Definer den utvidede konfigurasjonstypen, som nå inkluderer våre utvidelser.
// Denne typen er avledet fra den utvidede `AppConfig`-deklarasjonen.
interface ExtendedAppConfig extends OriginalAppConfig {
  environment: 'development' | 'staging' | 'production';
  featureFlags: Record;
}

// Lever den faktiske implementasjonen for konfigurasjonen.
// Dette objektet må samsvare med `ExtendedAppConfig`-typen.
export const config: ExtendedAppConfig = {
  apiUrl: 'https://api.example.com',
  timeout: 10000,
  environment: process.env.NODE_ENV as 'development' | 'staging' | 'production' || 'development',
  featureFlags: {
    newUserDashboard: true,
    internationalPricing: false,
  },
};

// Eventuelt, hvis det opprinnelige biblioteket forventet en standardeksport og vi vil opprettholde det:
// export default config;

// Hvis det opprinnelige biblioteket eksporterte `config` direkte, kan du gjøre:
// export * from 'config'; // Importer originale eksporter
// export const config = { ...originalConfig, environment: '...', featureFlags: {...} }; // Overstyr eller utvid

// Nøkkelen er at denne `config.ts`-filen gir kjøretidsverdiene for `environment` og `featureFlags`.

            

              
                Copy
              
            
          

            
// src/main.ts

import { config } from './config'; // Importer fra din utvidede konfigurasjonsfil

console.log(`API URL: ${config.apiUrl}`);
console.log(`Nåværende miljø: ${config.environment}`);
console.log(`Nytt bruker-dashboard aktivert: ${config.featureFlags.newUserDashboard}`);

if (config.environment === 'production') {
  console.log('Kjører i produksjonsmodus.');
}

            

              
                Copy
              
            
          

            
// src/types/express.d.ts

import 'express'; // Signaliser utvidelse for 'express'-modulen

declare global {
  // Utvidelse av det globale Express-navnerommet er også vanlig for rammeverk.
  // Eller, hvis du foretrekker modulutvidelse for express-modulen selv:
  // declare module 'express' {
  //   interface Request {
  //     user?: { id: string; username: string; roles: string[]; };
  //   }
  // }

  // Bruk av global utvidelse er ofte mer rett frem for rammeverkets request/response-objekter.
  namespace Express {
    interface Request {
      // Definer typen for den egendefinerte brukeregenskapen.
      user?: {
        id: string;
        username: string;
        roles: string[];
        // Legg til andre relevante brukerdetaljer.
      };
    }
  }
}

            

              
                Copy
              
            
          

            
// src/middleware/auth.ts

import { Request, Response, NextFunction } from 'express';

// Denne middlewaren vil legge til brukerinformasjon til request-objektet.
export const authenticateUser = (req: Request, res: Response, next: NextFunction) => {
  // I en ekte app ville du hentet dette fra et token, database, etc.
  // For demonstrasjon, hardkoder vi det.
  const isAuthenticated = true; // Simuler autentisering

  if (isAuthenticated) {
    // TypeScript vet nå at req.user er tilgjengelig og har riktig type
    req.user = {
      id: 'user-123',
      username: 'alice_wonder',
      roles: ['admin', 'editor'],
    };
    console.log(`Bruker autentisert: ${req.user.username}`);
  } else {
    console.log('Autentisering feilet.');
    // Håndter uautentisert tilgang (f.eks. send 401)
    return res.status(401).send('Unauthorized');
  }

  next(); // Gi kontrollen videre til neste middleware eller rutehåndterer
};

            

              
                Copy
              
            
          

            
// src/app.ts

import express, { Request, Response } from 'express';
import { authenticateUser } from './middleware/auth';

const app = express();
const port = 3000;

// Bruk autentiserings-middlewaren på alle ruter eller spesifikke ruter.
app.use(authenticateUser);

// En beskyttet rute som bruker den utvidede req.user-egenskapen.
app.get('/profile', (req: Request, res: Response) => {
  // TypeScript utleder korrekt at req.user eksisterer og har de forventede egenskapene.
  if (req.user) {
    res.send(`Velkommen, ${req.user.username}! Dine roller er: ${req.user.roles.join(', ')}.`);
  } else {
    // Dette tilfellet bør teoretisk sett ikke nås hvis middlewaren fungerer korrekt,
    // men det er god praksis for uttømmende sjekker.
    res.status(401).send('Ikke autentisert.');
  }
});

app.listen(port, () => {
  console.log(`Server lytter på port ${port}`);
});

            

              
                Copy