Repository navigation
Breaking change: std::string_view usage in 8.8.0 breaks C++14 compatibility #1737
Description
Version: 8.8.0
Regression from: 8.7.x (confirmed working)
std::string_view is a c++17 feature, meaning the changes in 8.8.0 break compatibility with c++14.
Questions for the maintainers:
- Was the C++14 compatibility drop intentional?
- If so, would this not be a reason to bump a mayor version?
Activity
KevinEady commentedon Jun 17, 2026
Hi @GerjandeGroot ,
Our build requirements match those of Node.js, which IIRC is C++17 in Node.js v22.
BYVoid commentedon Jun 24, 2026
Independently reproduced on 8.8.0 while building an addon with
-std=c++14. Two things that may help narrow the fix:1. It's not only
std::string_view—if constexpris also used (C++17).Even if the
string_viewoverloads were guarded, the header still won't compile as C++14 because ofif constexprin theObjectWrapfinalizer path:napi-inl.h:1379,1426—std::string_view(Symbol::New)napi-inl.h:1267—String::New(env, val.data(), val.size())(follows from thestring_viewoverload)napi-inl.h:5338,5348—if constexpr (details::HasBasicFinalizer<T>::value)/HasExtendedFinalizerSo restoring C++14 support would require guarding both constructs, not just
string_view.2. Clang masks the regression; GCC does not.
With GCC 16 at
-std=c++14it's a hard error:With Clang + libc++ at
-std=c++14the same code only produces warnings ('std::string_view' ... C++17,-Wc++17-extensionsforif constexpr) and compiles successfully. CI that builds only with Clang/libc++ will not catch this — which is likely how it shipped in 8.8.0.3. For the record — where the "C++14" baseline actually comes from.
node-addon-api itself doesn't document a minimum C++ standard. I grepped the whole repo (docs,
*.gyp/*.gypi, CMake) and there is no stated baseline anywhere — the onlycplusplushits are links to cppreference. The C++14 expectation comes from Node's bundledcommon.gypi(the one node-gyp includes when compiling an addon), not from any node-addon-api doc:-stdincommon.gypignu++1y(C++14 draft)gnu++14gnu++17gnu++20So default node-gyp builds on currently-supported Node (18+) are already ≥C++17 and unaffected. The breakage surfaces for (a) builds that explicitly set
-std=c++14(this issue, plus non-node-gyp build systems like CMake/Bazel that pick the standard themselves), and (b) older/EOL Node toolchains (≤16). Given that, it would help to document node-addon-api's actual minimum standard (now effectively C++17) rather than leave it implicit — and ideally add a-std=c++14GCC build in CI to prevent silent regressions like this.KevinEady commentedon Jul 31, 2026
We discussed in the 31 July 2028 Node-API meeting. We will update the README.md documentation to state that the minimum supported C++ version is the same version that is required by the minimum supported Node.js.
According to our package.json:
node-addon-api/package.json
Lines 478 to 480 in 7223518
The minimum supported Node.js is 18.x, which required C++17.
Once we update the documentation, we will close this issue.
GerjandeGroot commentedon Jul 31, 2026
Thank you, that will clear things up.