packages/node-addon-examples/scripts/copy-examples.mts carries a list of upstream examples we deliberately skip. Most entries are disabled for reasons we accept and won't fix (they use worker_threads, process.argv, node:events, uv.h, or bring their own CMake project). Five carry TODOs instead — i.e. we intend to enable them:
https://github.com/callstackincubator/react-native-node-api/blob/29a527d87fa8cb965b0048b1b4c1cff2b0eab281/packages/node-addon-examples/scripts/copy-examples.mts#L19-L28
https://github.com/callstackincubator/react-native-node-api/blob/29a527d87fa8cb965b0048b1b4c1cff2b0eab281/packages/node-addon-examples/scripts/copy-examples.mts#L38-L40
Three distinct blockers:
- Lambda functions — blocks
1-getting-started/6_object_wrap/napi/, 1-getting-started/7_factory_wrap/napi/ and 2-js-to-native-conversion/8_passing_wrapped/napi/. Three examples for one fix, so this is the highest-value of the three.
noexcept — blocks 2-js-to-native-conversion/object-template-demo/napi/.- Output-directory mismatch — as the
TODO notes, gyp-to-cmake should produce projects whose output directory matches what gyp would have produced, so that examples with a require pointing at the conventional gyp path resolve. That would unblock 5-async-work/napi-asyncworker-example/node-addon-api/ and 6-threadsafe-function/promise-callback-demo/node-addon-api/, both currently disabled with "require statement to an unexpected path".
The first two say "Fix C++ support", which is worth pinning down before anyone starts: it is not obvious from the comments whether the failure is in gyp-to-cmake's translation, in a C++ standard/flag we pass, or in the host's C++ surface. Reproducing one of the lambda cases and capturing the actual compiler error is the first step.
Each of the three can land independently. Related to the other gyp-to-cmake gaps: #98, #99, #100, #101, #102, #103.
packages/node-addon-examples/scripts/copy-examples.mtscarries a list of upstream examples we deliberately skip. Most entries are disabled for reasons we accept and won't fix (they useworker_threads,process.argv,node:events,uv.h, or bring their own CMake project). Five carryTODOs instead — i.e. we intend to enable them:https://github.com/callstackincubator/react-native-node-api/blob/29a527d87fa8cb965b0048b1b4c1cff2b0eab281/packages/node-addon-examples/scripts/copy-examples.mts#L19-L28https://github.com/callstackincubator/react-native-node-api/blob/29a527d87fa8cb965b0048b1b4c1cff2b0eab281/packages/node-addon-examples/scripts/copy-examples.mts#L38-L40Three distinct blockers:
1-getting-started/6_object_wrap/napi/,1-getting-started/7_factory_wrap/napi/and2-js-to-native-conversion/8_passing_wrapped/napi/. Three examples for one fix, so this is the highest-value of the three.noexcept— blocks2-js-to-native-conversion/object-template-demo/napi/.TODOnotes,gyp-to-cmakeshould produce projects whose output directory matches whatgypwould have produced, so that examples with arequirepointing at the conventional gyp path resolve. That would unblock5-async-work/napi-asyncworker-example/node-addon-api/and6-threadsafe-function/promise-callback-demo/node-addon-api/, both currently disabled with "require statement to an unexpected path".The first two say "Fix C++ support", which is worth pinning down before anyone starts: it is not obvious from the comments whether the failure is in
gyp-to-cmake's translation, in a C++ standard/flag we pass, or in the host's C++ surface. Reproducing one of the lambda cases and capturing the actual compiler error is the first step.Each of the three can land independently. Related to the other
gyp-to-cmakegaps: #98, #99, #100, #101, #102, #103.