Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Port the make_callback test addon from #219 and enable node-api/test_async in node-tests

Ouverte
  • Quelque chose ne va pas ?
#403 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
55/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Calme
Stack technique
c, cmake, javascript, node.js, typescript
Domaine
build-system, testing-qa

Piste de recherche

Commencez par packages/node-addon-examples/src/index.ts, le modèle CMake de tests/async, scripts/copy-tests.mts et packages/node-tests/common.ts ; comparez les fichiers make_callback de #219 avec l’addon threadsafe-function de #398. Exécutez les vérifications du dépôt pour node-addon-examples et node-tests. C’est terminé lorsque l’addon est compilé et enregistré, que node-api/test_async est activé et que les deux chemins de test passent.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Two test-coverage follow-ups deferred from #398. Both validate functionality that Hermes' first-party Node-API implementation provides on its own (independent of the hermes_napi_host integration), so they were split out as test-infrastructure work.

1. Port the make_callback test addon from #219

napi_async_init / napi_async_destroy / napi_make_callback are provided natively by the vendored Hermes since the static_h adoption (the injector binds the full symbol surface), which obsoletes #219's host-side C++ implementation — but its test addon (tests/make_callback/: addon.c adapted from Node's own test plus a promise-less driver asserting receiver/argument/return-value plumbing) ports directly to the packages/node-addon-examples/tests/<name>/ pattern established there and in #398:

  • Copy addon.c, addon.js, binding.gyp from #219 (credit @paradowstack), add the checked-in CMakeLists.txt per the tests/async template and a package.json with a unique name (e.g. make-callback-test).
  • Register under suites.tests in packages/node-addon-examples/src/index.ts.

Expected to pass as-is against next — a failure would be a real conformance finding against Hermes' implementation.

2. Enable node-api/test_async in packages/node-tests

The entry exists but is commented out in scripts/copy-tests.mts's ALLOW_LIST. Two independent blockers:

  • common shims: the bundling pipeline aliases ../../common to packages/node-tests/common.ts, which currently only exports buildType. Upstream test.js uses common.mustCall. A faithful mustCall/mustCallAtLeast/mustNotCall needs a home for its verification step: upstream checks call counts at process exit, which has no analogue in the long-lived mocha-remote app — the shim needs a per-test verification hook wired into the generated suite (e.g. an afterEach-style flush exposed from common.ts).
  • <uv.h> in the C side: upstream test_async.c includes <uv.h> directly, so enabling it also needs a small uv shim along the lines of the pthread-based one written for tests/threadsafe-function/addon.c in #398 (or an upstream contribution making the test buildable without libuv).

Note on value: the behavioral coverage largely overlaps the hand-written tests/async addon (create/queue/cancel/delete, cancel-while-queued via pool saturation — upstream's MAX_CANCEL_THREADS 6 trick is the same one tests/async already uses — plus the #398 additions for thread identity and cancel-while-running). The win from enabling the upstream suite is conformance tracking against Node itself rather than new coverage, which is also why it wasn't a blocker for #398.

Langage dominant
TypeScript
Étoiles
191
Forks
10
Merge moyen
2 j 17 h
PR mergées (30 j)
3

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de callstackincubator/react-native-node-api

Toutes les issues de callstackincubator/react-native-node-api

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.