Split test_general into stable and experimental targets

Problem

The upstream test_general test in the Node.js repository compiles a single target with NAPI_EXPERIMENTAL, which links against all experimental Node-API symbols (node_api_set_prototype, node_api_post_finalizer). This means the addon cannot be loaded on runtimes that don't export every experimental symbol.

In the CTS, this forces all test_general JS test files to guard loadAddon behind a check for every experimental feature the addon links against. The result is that even stable API tests (like napi_strict_equals, napi_typeof, napi_instanceof, etc.) are silently skipped on runtimes that don't support all experimental features.

Proposed solution

Split the upstream test_general into separate targets:

1. Stable target — compiles without NAPI_EXPERIMENTAL, includes all stable API functions
2. Experimental target(s) — one per experimental feature, compiled with the appropriate NAPI_EXPERIMENTAL define

This would allow the CTS to test stable APIs independently of experimental feature support.

Current workaround

The CTS ports test_general as a single experimental addon (matching upstream), with all JS tests guarded behind experimentalFeatures.setPrototype && experimentalFeatures.postFinalizer.

References

• Upstream source: https://github.com/nodejs/node/tree/main/test/js-native-api/test_general
• Upstream binding.gyp defines NAPI_EXPERIMENTAL on the single target

Commencez par le répertoire upstream test/js-native-api/test_general et son binding.gyp, puis comparez la manière dont CTS porte actuellement l’unique target expérimental. Identifiez les regroupements de fonctionnalités stables et expérimentales décrits dans l’issue. Le travail est terminé lorsque les tests de l’API stable peuvent être chargés sans tous les symboles expérimentaux, tandis que les tests expérimentaux restent protégés séparément et peuvent être compilés.