Rollup-plugin-typescript2: Arquivo de digitação gerado na pasta errada dentro do objeto como rollup `input`

A opção de plug-in useTsconfigDeclarationDir é uma solução alternativa por enquanto.

Isso pode ser corrigido por # 142, lançado em 0.20.0

Olá @ezolenkom e @jakearchibald , não

Ao adicionar a opção useTsconfigDeclarationDir em meu plug-in de rollup, os arquivos de declaração não são mais criados. E atualizar para 0.20.1 não fez diferença, infelizmente.

@benkeen ao usar a opção de plugin useTsconfigDeclarationDir: true você também precisa ter declarationDir valor em tsconfig.json

tenho problemas semelhantes, o layout do meu projeto é assim:

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 resultado, tenho:

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

Funciona para mim em 0.20.1 com useTsconfigDeclarationDir: false - os arquivos d.ts vão para as pastas especificadas em output.[].dir . @benkeen, você poderia tentar de novo?

@AntonPilyak é por design - se d.ts estivesse indo para uma pasta sem subcaminhos, então se você tivesse subFolder1/one.ts e subFolder2/one.ts , um deles estaria sobrescrevendo o outro.

@ezolenko : este recurso, eu acho, cria mais inconveniências ao invés de resolver um problema real (devido a ser difícil manter toda aquela estrutura de diretório). Tenho que criar um script que copie todas essas declarações de tipo para a raiz do pacote e adicione os diretórios a .npmignore para criar um pacote que seja fácil de incluir. Eu sugiro que você crie esses diretórios adicionais SOMENTE para os arquivos de tipo com os mesmos nomes. E use um diretório definido na seção 'output' de rollup.config.json para o resto.

@AntonPilyak você pode ser capaz de usar useTsconfigDeclarationDir: true option, setup declarationDir em tsconfig, isto deve permitir que o próprio typescript manipule os caminhos de saída das tipificações.

Decidir se os subdiretórios devem ser usados ​​com base na exclusividade dos caminhos seria um pesadelo em um projeto em evolução, de repente sua digitação mudaria para uma subpasta apenas porque você adicionou um novo arquivo com o mesmo nome em uma pasta diferente.

Normalmente, se você quer digitações bonitas, você vai querer mesclá-los em um arquivo de qualquer maneira (havia um módulo npm que sempre esqueci o nome para isso)

Estou usando a versão 0.22.0 e tenho praticamente o mesmo problema que @AntonPilyak

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

E eu pego isso:

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

Obviamente, eu gostaria que os arquivos *.d.ts ficassem ao lado dos arquivos *.js e *.js.map .

Tentei brincar com useTsconfigDeclarationDir e declarationDir sem sucesso.

Os arquivos de definição sempre terminam dentro de lorem e ipsum subpastas respectivamente, e nunca em uma lista plana.

Além disso, parece que ele cria arquivos de declaração para cada arquivo .ts que encontra, não apenas para os pontos 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

Eu tentei definir o escopo options.tsconfigOverride.input apenas para os pontos de entrada, mas isso parece não surtir nenhum efeito. Na verdade, nem tenho certeza se tsconfigOverride.input funciona.

Isso tudo é um pouco confuso.

...

Quer dizer, é justo se for necessário criar um arquivo de declaração para utils/bar-helper.ts mas pelo menos wat.ts deve ser deixado de fora da coisa toda.

Sim, ele gera declarações para todos os arquivos encontrados pelo tsconfig, se você não quiser que um determinado arquivo seja tocado, certifique-se de que ele seja excluído ou não incluído no tsconfig. Para ver a lista de arquivos encontrados por typescript, execute o plugin com verbosidade 3 e procure a entrada "tsconfig analisado".

Para caminhos de definições, onde em seu exemplo você gostaria que a definição de 'src/ipsum/foo.ts' se sentasse?

Como é uma definição de dist/foo.js , presumi que terminaria próximo a ele - exatamente como o arquivo do mapa de origem - ou seja, dist/foo.d.ts .

O TypeScript saberá emparelhar dist/foo.js e dist/lorem/foo.d.ts ?

O cenário completo em que isso se desfaz é:
src / dir1 / foo.ts
src / dir2 / foo.ts

dir1 / foo.ts é definido como entrada de rollup e importa dir2 / foo.ts. O rollup criará o pacote dist / foo.js que conterá partes relevantes de ambos os arquivos de origem, mas o typescript precisa criar 2 arquivos de definição de tipo com o mesmo nome em algum lugar.

A solução fácil é usar subpastas, espelhando o layout de origem. Acho que é o que tsc faz, a menos que você diga a ele para mesclar as definições de tipo (rpt2 não oferece suporte à mesclagem de definições).

E sim, o texto datilografado saberá onde encontrar as definições de tipo. Portanto, além de ser um pouco confuso, isso não deve ser um problema. Se você deseja implantar o pacote com tipos no npm, defina "types" em package.json para o arquivo d.ts para seu ponto de entrada. O texto datilografado encontrará coisas de lá.

Ah, então este plugin realmente não gerencia nenhuma parte do processo de construção de declaração. Ele apenas dispara tsc para fazer seu trabalho, irrelevante para o processo de Rollup?

Ainda assim, se estou apenas expondo / publicando alguns módulos, por que desejaria que o TypeScript gerasse *.d.ts arquivos para cada arquivo ts que encontrar? Não há como limitá-lo apenas aos pontos de entrada?

O fato é que estou exportando um conjunto de módulos autônomos ( import tool1 from 'myTools/tool1'; etc.), portanto, não há um único ponto de entrada para usar em pkg.types . Cada arquivo de definição deve residir próximo a sua contraparte *.js para que o VSCode o pegue.

Pior ainda, se eu tiver

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

Eu recebo:

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

E agora não há como o TypeScript emparelhar dist/fooscript.js e dist/foo/index.d.ts .

...

Não há como seu plug-in alimentar o TypeScript com o caminho de destino / saída para cada arquivo de pacote JavaScript? Parece que o tsc está recebendo o nome do arquivo de entrada original e segurando-o firmemente ao gerar as declarações.
... ou para cada um dos arquivos de entrada, procure o arquivo *.d.ts e mova + renomeie-o para o destino do mapa do arquivo de entrada. (Você pode notar que estou falando da minha bunda aqui, então ... ;-)

Isso é algo que tento tentar manualmente depois que o Rollup terminar - mas seria muito melhor se o plug-in fizesse isso automaticamente.

Não, o plug-in usa LanguageServices (os mesmos IDEs de API de typecript que normalmente usam), então tenho algum controle sobre o que escrever e onde.

Para escrever uma definição de tipo por entrada de rollup, precisaremos mesclar as definições de todas as importações dessa entrada. O rollup pode estar vendo um arquivo ts de entrada, mas pode importar e agrupar qualquer número de arquivos de origem ao construí-los, esses tipos de necessidades gerados também.

Atualmente estou errando em gerar definições para tudo o que o typescript encontra ao examinar o arquivo tsconfig. Se eu gerar tipos apenas para módulos transpilados, os arquivos de tipo serão ignorados.

Talvez eu tenha que revisitar essa parte, a API mudou consideravelmente desde que essa parte foi feita ...

Terei que ver como fazer seu exemplo funcionar. Pode precisar de melhor suporte para vários pacotes em uma configuração de rollup.

Como você consome esse pacote depois de criá-lo? Não é algo que você pode publicar no npm e importar pelo nome do pacote ...

Estou fazendo uma coleção de utilitários autônomos. A pasta raiz do pacote publicado / instalado contém todos os arquivos de módulo construídos em uma lista plana.

(Estou escrevendo-os em TS / ES6 em uma estrutura de pasta aninhada, com arquivos de teste misturados e contando com o Rollup para convertê-los em uma lista simples de arquivos CJS com uma combinação eficiente de divisão de código e inlining para qualquer código compartilhado.)

Eu, então, consumi essas ferramentas importando-as por nome de arquivo - assim:

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

A ideia é que, por não ter um único ponto de entrada para todo o kit de ferramentas (sem entradas pkg.main ou pkg.module ), posso ficar despreocupado ao adicionar ferramentas raramente usadas, e mesmo experimentais sem adicionar peso / inchaço para os consumidores a jusante (que podem não ter uma agitação de árvore eficiente).

... Estou brincando um pouco com tsc na linha de comando e acho que agora vejo as limitações com as quais você está lidando.

Percebi, no entanto, que se você executar o tsc e definir o formato do módulo / saída para "amd" ou "system" , ele gera um único arquivo *.d.ts com uma lista organizada de todos os blocos declare module "..." embutidos.

Eu me pergunto se esse comportamento poderia ser explorado de alguma forma - via renomear / mover arquivo e desembrulhar / reescrever a última declaração do módulo (principal)?

Nota lateral: eu também noto que tsc não parece se esforçar muito para alterar esse arquivo de declaração. Em um caso, vejo um módulo principal (ponto de entrada) que exporta uma única assinatura de função muito simples e, ainda assim, o arquivo de declaração expõe blocos de declaração para todos os módulos privados usados ​​"nos bastidores". Engraçado. :-)

Oi de novo.
Por enquanto, estou configurando um declarationDir para tsc para despejar todos os *.d.ts em e, em seguida, executar um script autônomo que importa o mesmo arquivo de entrada para objeto de arquivo de saída conforme eu alimento para Rollup, e ele gera arquivos de declaração de nível de destino de pacote que simplesmente export * from o arquivo de declaração real.

Essencialmente, eu gerei dist/fooscript.d.ts que contém apenas:

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

É um hack autônomo feio, mas fornece resultados previsivelmente corretos.

Eu me pergunto se rollup-plugin-typescript2 poderia fazer algo semelhante?

Isso funcionaria, sim.

Eu tenho algumas idéias (quando eu chegar perto delas), por exemplo, gerar <bundlename>.d.ts que tem um monte de /// <reference types=""/> para cada d.ts envolvido.

Primeiro, posso ter que consertar o bug relacionado à geração de muitas declarações de tipo e limitar isso apenas ao arquivo raiz e qualquer coisa que ele realmente importe.

Algumas reflexões:

IMO, a única parte realmente feia do meu hack é o fato de que ele se destaca do processo de Rollup. Os intermediários *.d.ts são, na verdade, uma maneira bem legal e idiomática de fazer a ponte entre os pacotes gerados pelo Rollup e as definições de tsc .

Uma vez que os arquivos de declaração gerados por tsc referenciam uns aos outros por meio de caminhos relativos, é melhor deixar essa estrutura de arquivo / pasta sozinha - para que você não acabe reimplementando partes da funcionalidade de Rollup, para uma sintaxe de linguagem personalizada.

E se rollup-plugin-typescript2 definir algo como output.dir + '__types' como o declarationDir padrão, então qualquer confusão causada pela ansiedade excessiva de tsc é cuidadosamente eliminada vista dentro de uma pasta com nome claro. Dessa forma, os arquivos de definição irrelevantes se tornam uma preocupação menor da IMO.

FWIW, aqui está a essência do meu script:

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.');

Atualizei o exemplo acima, pois parece que as exportações padrão precisam ser reexportadas explicitamente.

Os testes preliminares indicam que a reexportação cega de default de um arquivo de declaração que não possui default export é inofensiva e silenciosamente ignorada. (Pelo menos por VSCode.)

Olá, esse problema deve ser resolvido na v0.23.0?

(... me perguntando se devo tentar atualizar meu projeto para eliminar todos os faffing personalizados)

0.23 não gerará declaração para tudo à vista, mas ainda gerará declarações que você realmente importa em suas subpastas relativas. Você provavelmente pode atualizar e ter tipos mais leves, mas ainda não há nada para gerar declarações de tipo de raiz.

Meu script de compilação de solução alternativa personalizada (veja acima) está gradualmente se infiltrando em mais e mais dos meus projetos. o_O

Para sua informação: O desenvolvimento do pacote oficial @ rollup / plugin-typescript foi retomado, e agora apresenta verificação de tipos e arquivos de declaração de saída, então, pessoalmente, estou mudando para usá-los.
As limitações são praticamente as mesmas, no entanto.

@maranomynet Você ainda confia em seu script para mover os arquivos de declaração após o rollup funcionar? Eu não tive muita sorte trocando sozinho.

Sim. essa parece ser a única maneira, a menos que você deixe tsc fazer o empacotamento de ponta a ponta.
Esses plug-ins de rollup parecem estar solicitando eficazmente ao tsc para fazer duas tarefas diferentes:

1. "Verifique por tipo e converta todos esses módulos individuais para JavaScript" e deixe-me (ou seja, Rollup) fazer o empacotamento e gravar no disco.
2. "Faça todas as declarações para esta pasta de projeto TS e despeje-as lá."

Os resultados de 1 e 2 não e não podem corresponder quando você está usando um "mapa de entrada" e divisão de código, etc. - AFAICT.

... a menos que você torne o plugin rollup muito mais envolvido no processo de geração de declaração de tipo.

Sim, foi isso o que imaginei, obrigado! Dei a você um 👍 pela sua resposta útil e o 👎 por como me sinto a respeito.

Teve sorte com isso?

Para qualquer pessoa com dificuldades que tenha a mesma estrutura de pasta src que @maranomynet e eu.

Eu encontrei uma solução rápida para isso, pode ser outra forma feia, mas funciona para mim.

Estou usando rollup-plugin / typescript2, então irei com sua configuração nesta resposta:
Defina sua própria declaraçãoDir em seu tsconfig.json para que seu projeto possa despejar todos os arquivos * .d.ts em seu próprio caminho no dist agrupado. E certifique-se de definir useTsConfigDeclarationDir como true em seu plug-in de typecript no arquivo de configuração de rollup.
Além disso, onde você define os caminhos de saída para seus pacotes de componentes individuais em rollup.config.js (e package.json), altere esses caminhos para que sejam iguais a seu 'declaraçãoDir' + 'como sua rota de componente src é'. Portanto, se o seu componente em src for como:

src / homepage / foo.tsx

E sua declaraçãoDir é:

dist / MyDeclarationDir

Portanto, seu caminho de saída deve ser como:

dist / MyDeclarationDir / homepage / foo.js

Dessa forma, o rollup incluirá seus tipos no mesmo diretório que seu componente main.js e seu projeto de consumidor de TS coletará as tipificações.

Portanto, o pacote será semelhante a:

dist /

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