Rollup-plugin-typescript2: Ne fonctionne pas avec le plugin qui contient la syntaxe async/wait

J'ai ajouté une solution de contournement pour ignorer tout ce que l'objet-hash ne peut pas traiter (voir la branche objecthash, option objectHashIgnoreUnknownHack ). Cependant, cela peut potentiellement rendre le cache périmé, ce n'est donc pas une bonne solution à long terme.

@wessberg

Je dois admettre que je suis surpris que cela n'ait pas été plus un problème jusqu'à présent, car les fonctions asynchrones sont maintenant extrêmement courantes 😀. C'est aussi pourquoi je pense que le simple fait de l'ignorer entraînera de nombreux problèmes de cache. Le PR que j'ai soumis à object-hash il y a quelque temps était une conséquence de ce problème même, et je suggérerais que vous supprimiez la dépendance à object-hash. Je suis assez confiant que le PR soumis il y a quelque temps fonctionnerait très bien car il correspond à la même valeur que celle fournie dans le message d'erreur et a réussi les deux tests unitaires et a résolu les problèmes de ce plugin, alors n'hésitez pas à dépendre du PR plutôt que le package NPM ici.

@vwxyutarooo , une solution de contournement immédiate consiste à définir clean: true dans la configuration pour contourner complètement le cache. Alternativement (désolé pour la prise), j'ai construit https://github.com/wessberg/rollup-plugin-ts qui fonctionnera également très bien

@wessberg Oui, je suppose que peu de plugins de cumul ont encore une synchronisation dans leur interface.

Connaissez-vous une meilleure façon de hacher des objets? Je dois créer une clé de cache basée en partie sur l'objet de configuration de cumul (et contenant donc la source de tous les plugins utilisés) qui est transmise au démarrage.

btw, pour clarifier -- le problème s'applique aux trucs asynchrones dans la configuration de cumul elle-même. L'async dans le code en cours de transpilation n'est pas un problème, car le code est haché en fonction du texte source.

Hmm, eh bien, vous pouvez appliquer sha1 au résultat de JSON.stringify'ing toute la configuration avec un remplaçant personnalisé qui mappe les plugins à leur propriété name qui, j'en suis sûr, est nécessaire.
Par exemple, la configuration de cumul suivante :

{
  // ...
  treeshake: true,
  plugins: [
    myPlugin1(),
    myPlugin2()
  ],
  // ...
}

Pourrait être converti dans la représentation JSON suivante :

{
  "treeshake": true,
  "plugins": [
    "name-of-my-plugin-1",
    "name-of-my-plugin-2"
  ]
}

Et puis vous pourriez appliquer sha1 et obtenir une chaîne base64 ou quelque chose comme ça que vous pourriez utiliser comme clé de cache ?

Je pensais dans ce sens, mais cela n'enlèverait-il pas encore plus de choses à prendre en compte pour le cache ? Je soupçonne que object-hash été créé spécifiquement parce que JSON.stringify jette tout ce qui n'est pas une propriété de valeur simple, un tableau ou un dictionnaire - il n'y a rien d'autre dans la spécification json.

Je suppose que je pourrais incorporer un hachage de package-lock,json et l'équivalent en fil, s'il y avait un moyen fiable de les trouver. (pour atténuer l'effet de l'option objectHashIgnoreUnknownHack )

Merci les gars de discuter de ce problème. En fait, l'option clean: true ne contourne pas le processus de mise en cache, donc cela ne fonctionne même pas pendant un certain temps. Cependant, ignoreUnknown pourrait éventuellement être le moyen de résoudre ce problème, comme le dit @ezolenko . J'attendrai 0,16.2 de toute façon !

@vwxyutarooo , je supposais que clean: true utilise une stratégie de cache noop. C'est ce dont je me souviens que @ezolenko a implémenté il y a quelque temps. S'il tente toujours de calculer une clé de cache à partir de la configuration de cumul, ce comportement doit être examiné à mon avis

Je ne sais pas comment cela a affecté au premier résultat-hachage objet, mais le objectHashIgnoreUnknownHack option objecthash branche est fonctionne pour moi.

J'ai retravaillé un peu le cache pour que clean: true n'invoque même pas le hachage d'objet et j'ai tout fusionné dans le maître. je sortirai dans quelques jours

En 0.17.0 maintenant

Pour une autre solution de contournement n'utilisant pas le hack objectHashIgnoreUnknownHack , j'ai rencontré ce problème en utilisant rollup-plugin-require-context , et l'extrait suivant semble fonctionner :

import requireContextORIGINAL from 'rollup-plugin-require-context'

const requireContext = (options) => {
  const plugin = requireContextORIGINAL(options)
  return {
    name: plugin.name,
    transform(code, id) {
      return plugin.transform(code, id)
    }
  }
}

À savoir, faire de transform une fonction normale renvoyant une promesse.

J'ai pensé que j'ajouterais une mise à jour pour les gens ici que la cause première ici a finalement été corrigée dans https://github.com/puleos/object-hash/pull/90 (très similaire à https://github.com/puleos/ object-hash/pull/68 référencé ci-dessus) et ici en #203. Pas besoin d'utiliser objectHashIgnoreUnknownHack pour prendre en charge les plugins asynchrones et plus de problèmes de cache -- vient de sortir en tant que v0.26.0 🎉 😄