← Back to TypeScript Course | Chapter 28: Real World Projects | Lesson 5 of 14

TypeScript के साथ Library

TypeScript reusable libraries के लिए well suited है क्योंकि यह JavaScript output के साथ declaration files generate कर सकता है। Consumers को runtime code और editor-friendly types दोनों मिलते हैं।
Syntax
typescript
// tsconfig.json: "declaration": true, "outDir": "dist"
export function functionName(param: ParamType): ReturnType {
    // ...
}

Core Concept

TypeScript में एक publishable library लिखने का मतलब है कि compiler runtime .js output और .d.ts declaration files दोनों generate करता है, इसलिए जो भी आपका package install करे उसे बिना आपके source की ज़रूरत के free में पूरी type information मिलती है।

उदाहरण: Core Concept

typescript
export function parseDate(input: string): Date {
  return new Date(input);
}
console.log(parseDate("2024-01-01"));

Basic Setup

एक basic setup tsconfig.json में "declaration": true और "outDir": "dist" set करता है, और package.json का "types" field emitted .d.ts entry file की ओर point करता है इसलिए consumers के editors इसे automatically pick up करते हैं।

उदाहरण: Basic Setup

typescript
// tsconfig.json: { "compilerOptions": { "declaration": true, "outDir": "dist" } }
// package.json: { "types": "dist/index.d.ts" }
console.log("declaration output ships .d.ts files alongside compiled JS");

Typed Example

एक typed example: अपनी library से export function parseDate(input: string): Date export करने का मतलब है कि एक consumer का editor hover पर exact parameter और return types दिखाता है, बिना किसी separate @types package की ज़रूरत के।

उदाहरण: Typed Example

typescript
export function parseDate(input: string): Date {
  return new Date(input);
}
// A consumer's editor shows this exact signature on hover, no @types needed.
console.log(parseDate("2024-06-15").getFullYear());

Project Usage

एक असली project में, अपनी library की public API surface को deliberately छोटी और well-typed रखना (हर internal helper export करने के बजाय) future changes को आसान बनाता है, क्योंकि जो export नहीं किया गया उसे consumers को तोड़े बिना freely refactor किया जा सकता है।

उदाहरण: Project Usage

typescript
// Only export the small, intentional public surface:
export function formatCurrency(amount: number): string {
  return `$${amount.toFixed(2)}`;
}
// internalHelper() stays unexported and freely refactorable.
console.log(formatCurrency(19.99));

Best Practices

अपनी library की own test suite कभी-कभी *compiled* .d.ts output के against चलाएं (सिर्फ source नहीं), क्योंकि एक valid-looking source file कभी-कभी ऐसा declaration output produce कर सकती है जो आपके intent से असल में match न करे।

उदाहरण: Best Practices

typescript
export interface LibraryConfig {
  apiKey: string;
}
export function configure(config: LibraryConfig): void {
  console.log("Configured with", config.apiKey);
}
// Occasionally test against the compiled .d.ts output, not just source.
configure({ apiKey: "abc" });
Related Topics
{# common_mistakes/chapter_summary/browser_support: on Hindi pages the view already swaps in the hi_ translation fields (or blanks these out if untranslated), so this renders correctly for both languages without a lang_code check here. #}
आम गलतियां
  1. "declaration": true भूल जाना, इसलिए consumers को कोई .d.ts types नहीं मिलतीं।
  2. package.json में main या types को src/ की ओर point करना, built dist/ folder के बजाय।
  3. हर internal helper export करना, जो public API को बाद में बदलना मुश्किल बनाता है।

Login to run this code

C/C++/Java/PHP execution requires a free account. Your code is saved — you'll land right back in the editor after logging in.