Rollup-plugin-typescript2: Fichier de saisie généré dans le mauvais dossier dans l'objet en tant que cumul "d'entrée"

L'option de plugin useTsconfigDeclarationDir est une solution de contournement pour le moment.

Cela pourrait être corrigé par #142, publié en 0.20.0

Salut @ezolenkom & @jakearchibald , pas de chance non plus en fait.

Lors de l'ajout de l'option useTsconfigDeclarationDir dans mon plugin rollup, les fichiers de déclaration ne sont plus créés du tout. Et la mise à jour vers 0.20.1 n'a malheureusement pas fait de différence.

@benkeen lors de l'utilisation useTsconfigDeclarationDir: true option de plugin declarationDir dans tsconfig.json

ont des problèmes similaires, la mise en page de mon projet est comme ceci :

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'
                      .....                      
                     }
    ],
     ...
  },
]

En sortie j'ai :

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

Fonctionne pour moi sur 0.20.1 avec useTsconfigDeclarationDir: false -- les fichiers d.ts vont dans les dossiers spécifiés dans output.[].dir . @benkeen pouvez-vous réessayer ?

@AntonPilyak c'est par conception - si d.ts allait dans un dossier sans sous-chemins, alors si vous aviez subFolder1/one.ts et subFolder2/one.ts , l'un d'entre eux en écraserait un autre.

@ezolenko : cette fonctionnalité, je pense, crée plus d'inconvénients plutôt que de résoudre un vrai problème (car il est difficile de maintenir toutes ces structures de répertoires). Je dois créer un script qui copie toutes ces déclarations de type à la racine du bundle et ajouter les répertoires à .npmignore afin de créer un bundle facile à inclure. Je vous suggère de créer ces répertoires supplémentaires UNIQUEMENT pour les fichiers de type portant les mêmes noms. Et utilisez un répertoire défini dans la section 'output' de rollup.config.json pour le reste.

@AntonPilyak, vous pourrez peut-être utiliser l'option useTsconfigDeclarationDir: true , configurez declarationDir dans tsconfig, cela devrait laisser le script lui-même gérer les chemins de sortie des frappes.

Décider si les sous-répertoires doivent être utilisés en fonction de l'unicité des chemins serait un cauchemar dans un projet en évolution, soudainement votre saisie se déplacerait vers un sous-dossier uniquement parce que vous avez ajouté un nouveau fichier avec le même nom dans un dossier différent.

Normalement, si vous voulez de jolies frappes, vous voudrez quand même les fusionner en un seul fichier (il y avait un module npm dont j'oublie sans cesse le nom pour cela)

J'utilise la version 0.22.0 et j'ai à peu près le même problème que @AntonPilyak

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

Et je sors ça :

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

Évidemment, j'aimerais que les fichiers *.d.ts soient placés à côté des fichiers *.js et *.js.map .

J'ai essayé de jouer avec useTsconfigDeclarationDir et declarationDir en vain.

Les fichiers de définition finissent toujours dans les sous-dossiers lorem et ipsum respectivement, et jamais dans une liste plate.

De plus, il semble qu'il crée des fichiers de déclaration pour chaque fichier .ts qu'il trouve, pas seulement les points d'entrée.

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

J'ai essayé de limiter options.tsconfigOverride.input uniquement aux points d'entrée, mais cela semble n'avoir aucun effet. En fait, je ne suis même pas sûr que tsconfigOverride.input fonctionne.

Tout cela est un peu confus.

...

Je veux dire, assez juste s'il a besoin de créer un fichier de déclaration pour utils/bar-helper.ts mais au moins wat.ts doit être laissé de côté.

Oui, il génère des déclarations pour tous les fichiers trouvés par tsconfig, si vous ne voulez pas qu'un fichier particulier soit touché, assurez-vous qu'il est exclu ou non inclus dans tsconfig. Pour voir la liste des fichiers trouvés par dactylographe, exécutez le plugin avec verbosity 3 et recherchez l'entrée "parsed tsconfig".

Pour le chemin des définitions, où dans votre exemple voudriez-vous que la définition de 'src/ipsum/foo.ts' se trouve ?

Puisqu'il s'agit d'une définition de dist/foo.js j'avais supposé que cela finirait à côté - tout comme le fichier de carte source - c'est-à-dire dans dist/foo.d.ts .

TypeScript saura-t-il associer dist/foo.js et dist/lorem/foo.d.ts ?

Le scénario complet où cela se décompose est :
src/dir1/foo.ts
src/dir2/foo.ts

dir1/foo.ts est défini comme entrée de cumul et importe dir2/foo.ts. Rollup créera un bundle dist/foo.js qui contiendra les parties pertinentes des deux fichiers source, mais le script dactylographié doit créer 2 fichiers de définition de type avec le même nom quelque part.

La solution simple consiste à utiliser des sous-dossiers, en reflétant la disposition de la source. Je pense que c'est aussi ce que fait tsc , à moins que vous ne lui disiez de fusionner les définitions de types (rpt2 ne prend pas en charge la fusion de définitions).

Et oui, tapuscrit saura où trouver les définitions de type. Donc, en plus d'être un peu désordonné, cela ne devrait pas être un problème. Si vous souhaitez déployer un package avec des types sur npm, définissez "types" dans package.json sur le fichier d.ts pour votre point d'entrée. Typescript trouvera des choses à partir de là.

Ah, donc ce plugin ne gère vraiment aucune partie du processus de génération de déclaration. Il lance juste tsc pour faire son travail, sans rapport avec le processus de Rollup ?

Pourtant, si je n'expose/publie que quelques modules, pourquoi voudrais-je que TypeScript génère des fichiers *.d.ts pour chaque fichier ts qu'il rencontre ? N'y a-t-il aucun moyen de le limiter aux seuls points d'entrée ?

Le fait est que j'exporte un ensemble de modules autonomes ( import tool1 from 'myTools/tool1'; etc.) donc il n'y a pas de point d'entrée unique à utiliser dans pkg.types . Chaque fichier de définition doit résider à côté de son équivalent *.js pour que VSCode le récupère.

Pire encore, si j'ai

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

Je reçois:

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

Et maintenant, il n'y a aucun moyen pour TypeScript de jumeler dist/fooscript.js et dist/foo/index.d.ts .

...

Votre plugin ne pourrait-il pas fournir à TypeScript le chemin de destination/sortie pour chaque fichier de bundle JavaScript ? Il semble que tsc reçoive le nom de fichier d'entrée d'origine et le conserve bien lors de la génération des déclarations.
...ou pour chacun des fichiers d'entrée, recherchez le fichier *.d.ts correspondant et déplacez-le + renommez-le vers la destination de la carte du fichier d'entrée. (Vous remarquerez peut-être que je parle de mon cul ici, alors... ;-)

C'est quelque chose que je suis obligé d'essayer manuellement après la fin du rollup - mais ce serait tellement mieux si le plugin le gère automatiquement.

Non, le plugin utilise LanguageServices (les mêmes IDE d'API dactylographiés sont généralement utilisés), donc j'ai un certain contrôle sur ce qu'il faut écrire et où.

Pour écrire une définition de type par entrée de cumul, nous devrons fusionner les définitions de toutes les importations pour cette entrée. Le cumul peut voir un fichier ts d'entrée, mais il peut importer et regrouper un nombre quelconque de fichiers source lors de la création de celui-ci, ces types doivent également être générés.

Actuellement, je me trompe du côté de la génération de définitions pour tout ce que le texte dactylographié trouve en regardant le fichier tsconfig. Si je génère des types uniquement pour les modules transpilés, les fichiers de type uniquement seront ignorés.

Je devrais peut-être revoir cette partie, l'API a considérablement changé depuis que cette partie a été terminée ...

Je vais devoir regarder comment faire fonctionner votre exemple. Peut-être besoin d'une meilleure prise en charge de plusieurs bundles dans une configuration de cumul.

Comment consommez-vous ce package après l'avoir construit? Ce n'est pas quelque chose que vous pouvez publier sur npm et importer par nom de package ...

Je fais une collection d'utilitaires autonomes. Le dossier racine du package publié/installé contient tous les fichiers du module construit dans une liste plate.

(Je les écris dans TS/ES6 dans une structure de dossiers imbriquée, avec des fichiers de test mélangés, et je m'appuie sur Rollup pour les convertir en une liste plate de fichiers CJS avec un mélange efficace de fractionnement de code et d'incorporation pour tout code partagé.)

Je consomme ensuite ces outils en les important par nom de fichier – comme ceci :

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

L'idée est qu'en n'ayant pas de point d'entrée unique pour l'ensemble de la boîte à outils (pas d'entrées pkg.main ou pkg.module ), je peux ajouter sans souci des outils rarement utilisés, et même expérimentaux. sans ajouter de poids/gonflement pour les consommateurs en aval (qui pourraient ne pas avoir de secouage efficace des arbres).

... J'ai un peu joué avec tsc sur la ligne de commande, et je pense que je vois maintenant les limites auxquelles vous faites face.

J'ai remarqué, cependant, que si vous exécutez tsc et définissez le format de module/sortie sur "amd" ou "system" , il génère un seul fichier *.d.ts avec une liste soignée de tous les blocs declare module "..." nécessaires en ligne.

Je me demande si ce comportement pourrait être exploité d'une manière ou d'une autre - via renommer/déplacer un fichier et déballer/réécrire la dernière déclaration de module (principal) ?

Remarque : je remarque également que tsc ne semble pas

Re-bonjour.
Pour l'instant, je définis un declarationDir pour tsc dans lequel vider tous les *.d.ts , puis j'exécute un script autonome qui importe le même fichier d'entrée vers- objet de fichier de sortie au fur et à mesure que j'alimente Rollup, et il génère des fichiers de déclaration au niveau de la destination du paquet qui se contentent de export * from le fichier de déclaration réel.

Essentiellement, je génère dist/fooscript.d.ts qui ne contient que :

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

C'est un hack autonome laid, mais il fournit des résultats corrects de manière prévisible.

Je me demande si rollup-plugin-typescript2 pourrait faire quelque chose de similaire ?

Cela fonctionnerait, ouais.

J'ai quelques idées (quand je les aborde), par exemple générer <bundlename>.d.ts qui a un tas de /// <reference types=""/> pour chaque d.ts impliqué.

Tout d'abord, je devrais peut-être corriger un bogue lié à la génération d'un trop grand nombre de déclarations de type et le limiter au seul fichier racine et à tout ce qu'il importe réellement.

Quelques réflexions :

OMI, la seule partie vraiment laide de mon hack est le fait qu'il se distingue du processus de Rollup. L'intermédiaire *.d.ts est en fait un moyen assez soigné et idiomatique de faire le pont entre les bundles générés par Rollup et les définitions de tsc .

Étant donné que les fichiers de déclaration générés par tsc réfèrent les uns aux autres via des chemins relatifs, il est probablement préférable de laisser cette structure de fichier/dossier seule - de peur que vous ne finissiez par réimplémenter des parties de la fonctionnalité de Rollup, pour une syntaxe de langage personnalisée.

Et si rollup-plugin-typescript2 définit quelque chose comme output.dir + '__types' comme valeur par défaut declarationDir , alors tout désordre causé par l'empressement excessif de tsc est soigneusement balayé. vue à l'intérieur d'un dossier clairement nommé. De cette façon, les fichiers de définition superflus deviennent une préoccupation très mineure pour l'OMI.

FWIW, voici la viande de mon 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.');

J'ai mis à jour l'exemple ci-dessus, car il semble que les exportations par défaut doivent être explicitement réexportées.

Des tests préliminaires indiquent que la réexportation aveugle de default partir d'un fichier de déclaration qui n'a pas d'exportation default est inoffensive et ignorée en silence. (Au moins par VSCode.)

Bonjour, ce problème devrait-il être résolu dans la v0.23.0 ?

(... je me demande si je devrais essayer de mettre à jour mon projet pour supprimer tous les trucs personnalisés)

0.23 ne générera pas de déclaration pour tout ce qui est en vue, mais il générera toujours des déclarations que vous importez réellement dans leurs sous-dossiers relatifs. Vous pouvez probablement mettre à jour et avoir des types plus légers, mais il n'y a encore rien pour générer des déclarations de type racine.

Mon script de génération de contournement personnalisé (voir ci-dessus) s'insinue progressivement dans de plus en plus de mes projets. o_O

Pour info : le développement du package officiel @rollup/plugin-typescript a depuis repris, et il propose désormais une vérification de type et des fichiers de déclaration de sortie, donc je suis personnellement en train de l'utiliser.
Cependant, les limites sont sensiblement les mêmes.

@maranomynet Comptez -vous toujours sur votre script pour déplacer les fichiers de déclaration une fois le rollup

Ouais. cela semble être le seul moyen à moins que vous ne laissiez tsc faire le regroupement de bout en bout.
Ces plug-ins de cumul semblent effectivement demander à tsc d'effectuer deux tâches différentes :

1. "Tapez et convertissez tous ces modules individuels en JavaScript" et laissez-moi (c'est-à-dire Rollup) faire le regroupement et l'écriture sur le disque.
2. "Faites toutes les déclarations pour ce dossier de projet TS et déposez-les là-bas."

Les résultats de 1 et 2 ne correspondent pas et ne peuvent pas correspondre lorsque vous utilisez une « carte d'entrée » et une division de code, etc. – AFAICT.

... à moins que vous ne rendiez le plug-in de cumul beaucoup plus impliqué dans le processus de génération de déclaration de type.

Ah ouais c'est un peu ce que je pensais, merci ! Je vous ai donné un 👍 pour votre réponse utile, et le 👎 correspond à ce que je ressens à ce sujet.

De la chance avec ça ?

Pour toute âme en difficulté qui a la même structure de dossiers src que @maranomynet et moi.

Je suis tombé sur une solution rapide pour cela, peut-être une autre façon laide mais fonctionne pour moi.

J'utilise rollup-plugin/typescript2 donc je vais utiliser sa configuration dans cette réponse :
Définissez votre propre declarationDir dans votre tsconfig.json afin que votre projet puisse vider tous les fichiers *.d.ts dans son propre chemin dans le dist fourni. Et assurez-vous de définir useTsConfigDeclarationDir sur true dans votre plug-in dactylographié dans le fichier de configuration de cumul.
De plus, lorsque vous définissez les chemins de sortie de vos ensembles de composants individuels dans votre rollup.config.js (et package.json), modifiez ces chemins pour qu'ils soient les mêmes que votre « declarationDir » + « comment est votre route de composant src ». Donc, si votre composant dans src ressemble à :

src/page d'accueil/foo.tsx

Et votre déclarationDir est :

dist/MyDeclarationDir

Votre chemin de sortie doit donc ressembler à :

dist/MyDeclarationDir/homepage/foo.js

De cette façon, le cumul inclura vos types dans le même répertoire que votre composant main.js et votre projet consommateur TS récupérera les saisies.

Le bundle ressemblera donc à quelque chose comme :

dist/

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