Rollup-plugin-typescript2: Archivo de tipos generado en la carpeta incorrecta dentro del objeto como paquete acumulativo de `entrada`

La opción del complemento useTsconfigDeclarationDir es una solución alternativa por ahora.

Esto podría ser arreglado por # 142, lanzado en 0.20.0

Hola @ezolenkom y @jakearchibald , no hubo suerte en ninguno de los dos.

Al agregar la opción useTsconfigDeclarationDir en mi complemento acumulativo, los archivos de declaración ya no se crean en absoluto. Y la actualización a 0.20.1 no hizo ninguna diferencia, desafortunadamente.

@benkeen al usar la opción de complemento useTsconfigDeclarationDir: true , también debe tener el declarationDir en tsconfig.json

tengo un problema similar, el diseño de mi proyecto es así:

export default [ 
  {
    input: 'src/subFolder1/one.ts,
    output: [
                    {
                      file: 'dist/one.js'
                      .....                      
                     }
    ],
    plugins: [
           typescript({
                typescript: require('typescript'),
            }),
    ]
  },
      input: 'src/subFolder2/two.ts,
      output: [
                    {
                      file: 'dist/two.js'
                      .....                      
                     }
    ],
     ...
  },
]

Como salida tengo:

  |---subFolder1
  |          |--------one.d.ts
  |
  |---subFolder2
  |          |---------two.d.ts
  |-----one.js
  |-----two.js

Me funciona en 0.20.1 con useTsconfigDeclarationDir: false - los archivos d.ts van a las carpetas especificadas en output.[].dir . @benkeen, ¿ podrías intentarlo de nuevo?

@AntonPilyak, eso es por diseño: si d.ts entrara en una carpeta sin subrutas, entonces si tuviera subFolder1/one.ts y subFolder2/one.ts , uno de esos estaría sobrescribiendo a otro.

@ezolenko : esta característica, creo, crea más inconvenientes en lugar de resolver un problema real (debido a que es difícil mantener toda esa estructura de directorios). Tengo que crear un script que copie todas estas declaraciones de tipo en la raíz del paquete y agregar los directorios a .npmignore para crear un paquete que sea fácil de incluir. Le sugiero que cree estos directorios adicionales SOLO para los archivos de tipo con los mismos nombres. Y use un directorio definido en la sección 'salida' de rollup.config.json para el resto.

@AntonPilyak, es posible que pueda usar la opción useTsconfigDeclarationDir: true , configurar declarationDir en tsconfig, esto debería permitir que el mecanografiado maneje las rutas de salida de mecanografía.

Decidir si los subdirectorios deben usarse en función de la singularidad de las rutas sería una pesadilla en un proyecto en evolución, de repente su escritura se movería a una subcarpeta solo porque agregó un nuevo archivo con el mismo nombre en una carpeta diferente.

Normalmente, si desea tipos bonitos, querrá fusionarlos en un archivo de todos modos (había un módulo npm del que sigo olvidando el nombre para eso)

Estoy usando la versión 0.22.0 y tengo prácticamente el mismo problema que @AntonPilyak

{
    ...
    input: {
        foo: 'src/lorem/foo.ts',
        bar: 'src/ipsum/bar.ts'
    },
    output: {
        dir: 'dist',
        format: 'cjs',
        sourcemap: true,
    }
}

Y saco esto:

dist/
    lorem/
        foo.d.ts
    ipsum/
        bar.d.ts
    foo.js
    foo.js.map
    bar.js
    bar.js.map

Obviamente, me gustaría que los archivos *.d.ts ubicaran junto a los archivos *.js y *.js.map .

He intentado jugar con useTsconfigDeclarationDir y declarationDir sin éxito.

Los archivos de definición siempre terminan dentro de las subcarpetas lorem y ipsum respectivamente, y nunca en una lista plana.

Además, parece que crea archivos de declaración para cada archivo .ts que encuentra, no solo los puntos de entrada.

dist/
    lorem/
        foo.d.ts
    ipsum/
        utils/
            bar-helper.d.ts
        bar.d.ts
     some_other_ts_file/
         not_imported_by/
             neither_foo_nor_bar/
                  wat.d.ts
    foo.js
    foo.js.map
    bar.js
    bar.js.map

Intenté establecer el alcance de options.tsconfigOverride.input solo en los puntos de entrada, pero eso parece no tener ningún efecto. De hecho, ni siquiera estoy seguro de si tsconfigOverride.input funciona en absoluto.

Todo esto es un poco confuso.

...

Quiero decir, es bastante justo si necesita crear un archivo de declaración para utils/bar-helper.ts pero al menos wat.ts debe dejarse fuera de todo.

Sí, genera declaraciones para todos los archivos encontrados por tsconfig, si no desea que se toque un archivo en particular, asegúrese de que esté excluido o no incluido en tsconfig. Para ver la lista de archivos encontrados por mecanografiado, ejecute el complemento con verbosity 3 y busque la entrada "tsconfig analizada".

Para la ruta de definiciones, ¿en qué lugar de su ejemplo le gustaría que se sentara la definición de 'src/ipsum/foo.ts' ?

Dado que es una definición de dist/foo.js , había asumido que terminaría junto a él, al igual que el archivo de mapa de origen, es decir, en dist/foo.d.ts .

¿TypeScript sabrá emparejar dist/foo.js y dist/lorem/foo.d.ts ?

El escenario completo donde esto se descompone es:
src / dir1 / foo.ts
src / dir2 / foo.ts

dir1 / foo.ts se establece como entrada acumulada e importa dir2 / foo.ts. Rollup creará un paquete dist / foo.js que contendrá partes relevantes de ambos archivos fuente, pero mecanografiado necesita crear 2 archivos de definición de tipo con el mismo nombre en alguna parte.

La solución fácil es utilizar subcarpetas, duplicando el diseño de la fuente. Creo que eso es lo que también hace tsc , a menos que le diga que combine las definiciones de tipo (rpt2 no admite la combinación de definiciones).

Y sí, mecanografiado sabrá dónde encontrar definiciones de tipo. Entonces, aparte de ser un poco complicado, esto no debería ser un problema. Si desea implementar un paquete con tipos en npm, configure "types" en package.json en el archivo d.ts para su punto de entrada. Typecript encontrará cosas a partir de ahí.

Ah, entonces este complemento no gestiona realmente ninguna parte del proceso de creación de declaraciones. Simplemente dispara tsc para hacer lo suyo, ¿irrelevante del proceso de Rollup?

Aún así, si solo estoy exponiendo / publicando un par de módulos, ¿por qué querría que TypeScript generara archivos *.d.ts para cada archivo ts que encuentre? ¿No hay forma de limitarlo solo a los puntos de entrada?

La cuestión es que estoy exportando un conjunto de módulos independientes ( import tool1 from 'myTools/tool1'; etc.) por lo que no hay un único punto de entrada para usar en pkg.types . Cada archivo de definición debe residir junto a su contraparte *.js para que VSCode lo recoja.

Peor aún, si tengo

{
    ...
    input: {
        fooscript: 'src/foo/index.ts',
        barscript: 'src/bar/index.ts'
    },
    output: {
        dir: 'dist',
        format: 'cjs',
        sourcemap: true,
    }
}

Yo obtengo:

dist/
    foo/
        index.d.ts
    bar/
        index.d.ts
    fooscript.js
    fooscript.js.map
    barscript.js
    barscript.js.map

Y ahora no hay forma de que TypeScript empareje dist/fooscript.js y dist/foo/index.d.ts .

...

¿No hay forma de que su complemento pueda alimentar a TypeScript con la ruta de destino / salida para cada archivo de paquete de JavaScript? Parece que tsc está recibiendo el nombre de archivo de entrada original y se aferra a él cuando genera las declaraciones.
... o para cada uno de los archivos de entrada, busque el archivo *.d.ts y muévalo + cámbiele el nombre al destino del mapa del archivo de entrada. (Puedes notar que estoy hablando mal aquí, así que ... ;-)

Esto es algo que estoy obligado a intentar manualmente después de que Rollup haya terminado, pero sería mucho mejor si el complemento lo manejara automáticamente.

No, el complemento usa LanguageServices (los mismos IDE de API mecanografiados suelen usar), por lo que tengo cierto control sobre qué escribir y dónde.

Para escribir una definición de tipo por entrada acumulada, necesitaremos fusionar definiciones para todas las importaciones para esa entrada. Rollup podría estar viendo un archivo ts de entrada, pero podría estar importando y agrupando cualquier cantidad de archivos de origen al compilarlos, esos tipos de necesidad también se generan.

Actualmente me equivoco al generar definiciones para todo lo que encuentra el mecanografiado al mirar el archivo tsconfig. Si genero tipos solo para módulos transpilados, se ignorarán los archivos de solo tipo.

Puede que tenga que volver a visitar esa parte, la API cambió considerablemente desde que se hizo esa parte ...

Tendré que ver cómo hacer que funcione tu ejemplo. Es posible que necesite un mejor soporte para varios paquetes en una configuración acumulada.

Sin embargo, ¿cómo consume ese paquete después de construirlo? No es algo que pueda publicar en npm e importar por nombre de paquete ...

Estoy haciendo una colección de utilidades independientes. La carpeta raíz del paquete publicado / instalado contiene todos los archivos del módulo construido en una lista plana.

(Los estoy escribiendo en TS / ES6 en una estructura de carpetas anidada, con archivos de prueba mezclados, y confío en Rollup para convertirlos en una lista plana de archivos CJS con una combinación eficiente de división de código e inserción para cualquier código compartido.)

Luego consumo estas herramientas importándolas por nombre de archivo, así:

import tool1 from 'myTools/tool1';
import tool2 from 'myTools/tool2';

La idea es que al no tener un único punto de entrada para todo el conjunto de herramientas (sin entradas de pkg.main o pkg.module ), puedo tener la libertad de agregar herramientas que rara vez se utilizan e incluso que son experimentales. sin agregar peso / hinchazón para los consumidores intermedios (que pueden no tener una sacudida eficiente de los árboles).

... He estado jugando un poco con tsc en la línea de comandos, y creo que ahora veo las limitaciones con las que estás lidiando.

Sin embargo, noté que si ejecuta tsc y configura el módulo / formato de salida en "amd" o "system" , genera un solo archivo *.d.ts con una lista ordenada de todos los bloques declare module "..." línea.

Me pregunto si este comportamiento podría explotarse de alguna manera, a través del cambio de nombre / movimiento del archivo y desenvolviendo / reescribiendo la última declaración del módulo (principal).

Nota al margen: también me doy cuenta de que tsc no parece poner mucho esfuerzo en sacudir ese archivo de declaración. En un caso, veo un módulo principal (punto de entrada) que exporta una firma de función única y muy simple y, sin embargo, el archivo de declaración expone bloques de declaración para todos los módulos privados utilizados "detrás de escena". Gracioso. :-)

Hola de nuevo.
Por ahora, estoy configurando un declarationDir para tsc para volcar todos los *.d.ts en, y luego ejecutar un script independiente que importa el mismo archivo de entrada a objeto de archivo de salida a medida que lo alimenta a Rollup, y genera archivos de declaración de nivel de destino de paquete que simplemente export * from el archivo de declaración real.

Básicamente, genero dist/fooscript.d.ts que solo contiene:

export *  from './__types/foo/index';

Es un truco independiente feo, pero proporciona resultados predeciblemente correctos.

Me pregunto si rollup-plugin-typescript2 podría hacer algo similar.

Eso funcionaría, sí.

Tengo un par de ideas (cuando me acerco a ellas), por ejemplo, generar <bundlename>.d.ts que tiene un montón de /// <reference types=""/> por cada d.ts involucrados.

Primero, podría tener que corregir un error relacionado con la generación de demasiadas declaraciones de tipo y limitar eso solo al archivo raíz y cualquier cosa que realmente importe.

Algunos pensamientos:

En mi opinión, la única parte verdaderamente fea de mi truco es el hecho de que se distingue del proceso de resumen. Los intermediarios *.d.ts son en realidad una forma bastante ordenada e idiomática de tender un puente entre los paquetes generados por Rollup y las definiciones de tsc .

Dado que los archivos de declaración generados por tsc referencia entre sí a través de rutas relativas, probablemente sea mejor dejar esa estructura de archivo / carpeta, para que no termine reimplementando partes de la funcionalidad de Rollup, para una sintaxis de lenguaje personalizada.

Y si rollup-plugin-typescript2 establece algo como output.dir + '__types' como el declarationDir predeterminado, entonces cualquier desorden causado por el exceso de entusiasmo de tsc se elimina cuidadosamente. vista dentro de una carpeta con un nombre claro. De esa manera, los archivos de definición extraños se convierten en una preocupación menor, en mi opinión.

FWIW, aquí está la parte esencial de mi guión:

const { makeInputMap, getEntrypoints, distFolder, srcFolder } = require('./buildHelpers');
const { writeFileSync } = require('fs');
const { relative } = require('path');

const srcPrefixRe = new RegExp('^' + srcFolder + '/');
const tsExtRe = /\.tsx?$/;

const declDirRelative = './' + relative(
  distFolder,
  require('../tsconfig.json').compilerOptions.declarationDir
);

const tsEntrypoints = getEntrypoints()
  .filter((fileName) => tsExtRe.test(fileName));

Object.entries(makeInputMap(tsEntrypoints))
  .forEach(([moduleName, sourcePath]) => {
    const tscDeclFile = sourcePath
      .replace(srcPrefixRe, declDirRelative + '/')
      .replace(tsExtRe, '');
    const outFile = distFolder + '/' + moduleName + '.d.ts';
    writeFileSync(
      outFile,
      [
        'export * from "' + tscDeclFile + '";',
        'import x from "' + tscDeclFile + '";',
        'export default x;',
        '',
      ].join('\n')
    );
  });

console.info('Created local declaration files for TypeScripted entrypoints.');

Actualicé el ejemplo anterior, ya que parece que las exportaciones predeterminadas deben reexportarse explícitamente.

Las pruebas preliminares indican que la reexportación ciega de default desde un archivo de declaración que no tiene una exportación default es inofensiva y se ignora en silencio. (Al menos por VSCode).

Hola, ¿debería resolverse este problema en v0.23.0?

(... preguntándome si debería intentar actualizar mi proyecto para eliminar todos los faffing personalizados)

0.23 no generará declaraciones para todo lo que esté a la vista, pero aún generará declaraciones que realmente importe en sus subcarpetas relativas. Probablemente pueda actualizar y tener tipos más ligeros, pero todavía no hay nada para generar declaraciones de tipo raíz.

Mi script de compilación de solución alternativa personalizada (ver arriba) se está infiltrando gradualmente en más y más de mis proyectos. o_O

FYI: Desde entonces se ha reanudado el desarrollo del paquete oficial @ rollup / plugin-typescript, y ahora presenta archivos de declaración de salida y verificación de tipos, así que personalmente voy a cambiar para usarlo.
Sin embargo, las limitaciones son muy parecidas.

@maranomynet ¿Todavía confía en su script para mover los archivos de declaración después de que el resumen hace su trabajo? No tuve mucha suerte al cambiarme.

Sí. esa parece ser la única forma a menos que deje que tsc haga la agrupación de principio a fin.
Estos complementos acumulativos parecen pedir eficazmente a tsc que realice dos tareas diferentes:

1. "Escriba-verifique y convierta todos estos módulos individuales a JavaScript" y déjeme (es decir, Rollup) agrupar y escribir en el disco.
2. "Haga todas las declaraciones para esta carpeta de proyecto de TS y bótelas allí".

Los resultados de 1 y 2 no coinciden y no pueden coincidir cuando se utiliza un "mapa de entrada" y división de código, etc. - AFAICT.

... a menos que haga que el complemento acumulativo esté mucho más involucrado en el proceso de generación de declaración de tipo.

Ah, sí, eso es lo que pensé, ¡gracias! Te di una 👍 por tu útil respuesta, y la 👎 es por lo que siento al respecto.

¿Tuviste suerte con esto?

Para cualquier alma en apuros que tenga la misma estructura de carpetas src que @maranomynet y yo.

Encontré una solución rápida, puede ser otra forma desagradable, pero funciona para mí.

Estoy usando rollup-plugin / typescript2, así que iré con su configuración en esta respuesta:
Defina su propia declaraciónDir en su tsconfig.json para que su proyecto pueda volcar todos los archivos * .d.ts en su propia ruta en el paquete dist. Y asegúrese de establecer useTsConfigDeclarationDir en verdadero en su complemento de mecanografiado en el archivo de configuración acumulativo.
Además, cuando defina las rutas de salida para sus paquetes de componentes individuales en su rollup.config.js (y package.json), cambie esas rutas para que sean las mismas que su 'DeclarationDir' + 'cómo es la ruta de su componente src'. Entonces, si su componente en src es como:

src / homepage / foo.tsx

Y tu declaraciónDir es:

dist / MyDeclarationDir

Entonces su ruta de salida debe ser como:

dist / MyDeclarationDir / homepage / foo.js

De esta manera, el resumen incluirá sus tipos en el mismo directorio que su componente main.js y su proyecto de consumidor de TS recogerá los tipos.

Entonces el paquete se verá así:

dist /

    declarationDirPath/
                  component1/
                        foo.js/
                              foo.js
                              foo.map.js
                        foo.d.ts
                   component2/
                        bar.js/
                               bar.js
                               bar.map.js
                        bar.d.ts