Búsqueda de sitios web

tsc - Sintaxis de módulo ES6 de Typescript con módulo ambient d.ts

Así que imaginemos que tengo un módulo de 50 archivos, y cada uno contiene:

export class <SomeClassName> { /* content */ }

Luego, creo un archivo raíz para simplificar el uso al reexportar todos los archivos. Así que se vería así:

export * from "./src/some-class-1";
export * from "./src/some-class-2";
export * from "./src/some-class-3";
// etc

Luego, lo ejecuto a través de TSC para hacer un módulo "común" dirigido a "es5" con salida de descriptor.

Hasta ahora todo bien. Tengo mi package.json con el nombre my-module que apunta al index.js generado como punto de entrada para mi módulo. Así que ahora voy y decido consumir este módulo en otro proyecto de TypeScript.

Así que hago el npm install para ello (hagamos de cuenta) npm install my-module y todo se descarga, así que ahora tengo los archivos d.ts que se generaron, y tengo el módulo CommonJS real para poder usarlo todo. Todo parece estar bien.

Entonces viene el problema. Entonces decido hacer uso del módulo:

import {SomeClass1} from 'my-module'

Explota como en el mundo de TS, no sabe a qué se refiere my-module, como si retrocediéramos y miráramos el index.js que se generó, no contiene un módulo ambiental.

Entonces aquí está el problema, los módulos comunes generalmente usan el package.json como punto de referencia al incluir nombres de módulos, sin embargo TS utiliza los archivos d.ts. Así que entonces pensé, bueno, necesito envolver mis re-exportaciones en index.ts en un módulo, así que lo intento:

export module "my-module" { /* all other re-exports */ }

Pero resulta que solo puedes usar nombres de módulos de cadena para los módulos ambientales, y solo puedes colocarlos dentro de archivos d.ts, sin embargo, mi archivo d.ts se genera a partir del código existente.

Entonces aquí está mi dilema, puedo entrar manualmente y agregar un envoltorio declare module "my-module" a mi d.ts, pero no es muy automatizado, o hacer como los blogs con sintaxis ES6 y referenciar el archivo de manera relativa, lo que terminaría con muchos import {blah} from "../node_modules/my-module/dist/index", lo cual, espero que todos podamos estar de acuerdo, es un poco absurdo.

Así que no puedo encontrar ningún otro enfoque que funcione en el mundo automatizado, ya que todas las publicaciones de blog y documentación sobre este tema, cuando se usa la sintaxis ES6, usan importaciones de archivos relativas, no importaciones de cuando todo ha sido compilado y compartido a través de archivos d.ts.

¿Entonces hay alguna manera aquí de envolver mis re-exportaciones en un nombre de módulo textual? ¿O al menos decirle al index.d.ts que esté contenido en un módulo ambiental? (como recuerda, generará un archivo d.ts para cada archivo en el proyecto, pero solo nos importa importar el módulo a través del index.d.ts ya que eso re-exporta todo).

Respuesta #1

En este momento todavía necesitas usar otra herramienta para generar un solo archivo .d.ts para tu paquete. Hay algunas herramientas que pueden hacer eso:

  • generador-dts
  • dts-bundle
  • autodts - tiene como objetivo facilitar el consumo de los .d.ts generados en los paquetes publicados en NPM

Personalmente, estoy usando una versión personalizada de dts-generator que hace uso de tsconfig.json y funciona con compilaciones nocturnas de TypeScript. Puedes ver un .d.ts que generó para uno de mis paquetes aquí.

Respuesta #2

Ok, finalmente lo tengo funcionando, bueno, al menos para CommonJS.

Ahora, con TypeScript 1.6, los cambios en la resolución de módulos de TS comprobarán la carpeta node_modules en busca de un archivo index.d.ts. Así que básicamente he agregado este archivo al final del proceso de compilación, que apunta a mi archivo dist/definitions/index.d.ts, el cual incluye todas las exportaciones.

De esta manera puedes hacer una importación como import * from "my-module" y mientras en tu carpeta node_modules tengas una carpeta my-module con un index.d.ts, básicamente tratará todo dentro de ese índice como un módulo.

Cambiaré la respuesta con gusto a otra si alguien más encuentra una mejor solución que funcione para todos y no solo para commonjs, pero por el momento es suficiente para que pueda avanzar y, con suerte, puede ayudar a alguien más.

Artículos relacionados