Repository navigation
Breaking change: std::string_view usage in 8.8.0 breaks C++14 compatibility #1737
Description
Activity
Hi @GerjandeGroot ,
Our build requirements match those of Node.js, which IIRC is C++17 in Node.js v22.
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 thestring_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)/HasExtendedFinalizer
So 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:napi-inl.h:1379:46: error: 'std::string_view' has not been declared note: 'std::string_view' is only available from C++17 onwardsWith 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:Node default -stdincommon.gypi14 gnu++1y(C++14 draft)16 gnu++1418 / 20 / 22 gnu++1724 gnu++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.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:
Lines 478 to 480 in 7223518
"engines": { "node": "^18 || ^20 || >= 21" } The minimum supported Node.js is 18.x, which required C++17.
Once we update the documentation, we will close this issue.
Thank you, that will clear things up.
- moved this from Need Triage to Done in Node-API Team Project
on Aug 21, 2026 - linked a pull request that will close this issuedoc: clarify minimum C++ standard #1754
on Aug 21, 2026
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsDone
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: