vm.Module.evaluate() morphs loader errors into module evaluation rejections
Personne n'a encore pris cette issue.
- Langage dominant
- JavaScript
- Étoiles
- 122k
- Forks
- 37.3k
- Merge moyen
- 4 j 2 h
- PR mergées (30 j)
- 283
Description
This came up in https://github.com/nodejs/node/pull/60205#discussion_r2423587581 when I was trying to make vm.Module.evaluate() return the module evaluation promise as-is (so synchronously fulfilled for synthetic modules and source text modules without TLA). Currently the validation errors, ERR_VM_MODULE_STATUS, THROW_ERR_SCRIPT_EXECUTION_TIMEOUT, and THROW_ERR_SCRIPT_EXECUTION_INTERRUPTED would always be rejected, so for a synchronous loader, they would either have to expose these underlying rejections to users when the loading goes wrong, or be forced to become asynchronous as it cannot catch these errors synchronously and paint it over. i.e. they cannot do something like this:
function syncLoad() {
try {
mod.evaluate();
} catch(e) { // This allows the user to get the loader errors synchronously
if (e.code === 'ERR_VM_MODULE_STATUS' ||
e.code === 'ERR_SCRIPT_EXECUTION_INTERRUPTED' ||
e.code === 'ERR_SCRIPT_EXECUTION_TIMEOUT') {
// fix it up and try again, or error and explain to user what to do
// but hide the errors that do not directly come from module code
// as implementation detail
}
}
if (mod.status === 'errored') {
throw mod.error; // It's an evaluation error from the module code
}
return mod.namespace;
}
Opening a separate issue to discuss if there's another way to make this possible other than just making it throw these loader errors synchronously.
Guide de contribution
Ouvrir le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Piste de recherche
Commencez par vm.Module.evaluate() et lisez la discussion de la pull request liée, en vous concentrant sur la manière dont les erreurs de validation et de loader sont actuellement remontées. L'issue est terminée lorsque le projet s'est mis d'accord sur une manière permettant aux loaders synchrones de distinguer les erreurs de loader des erreurs d'évaluation du module.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- javascript
- Domaine
- backend
- Type d'issue
- Fonctionnalité
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Activité
- Active
- Clarté
- À clarifier
- Accessibilité débutants
- 25/100