Skip to content

Breaking change: std::string_view usage in 8.8.0 breaks C++14 compatibility #1737

Description

@GerjandeGroot

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

  1. KevinEady commented on Jun 17, 2026

    @KevinEady
    Contributor

    Hi @GerjandeGroot ,

    Our build requirements match those of Node.js, which IIRC is C++17 in Node.js v22.

  2. BYVoid commented on Jun 24, 2026

    @BYVoid

    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 constexpr is also used (C++17).
    Even if the string_view overloads were guarded, the header still won't compile as C++14 because of if constexpr in the ObjectWrap finalizer path:

    • napi-inl.h:1379, 1426 — std::string_view (Symbol::New)
    • napi-inl.h:1267 — String::New(env, val.data(), val.size()) (follows from the string_view overload)
    • 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++14 it'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 onwards
    

    With Clang + libc++ at -std=c++14 the same code only produces warnings ('std::string_view' ... C++17, -Wc++17-extensions for if 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 only cplusplus hits are links to cppreference. The C++14 expectation comes from Node's bundled common.gypi (the one node-gyp includes when compiling an addon), not from any node-addon-api doc:

    Node default -std in common.gypi
    14 gnu++1y (C++14 draft)
    16 gnu++14
    18 / 20 / 22 gnu++17
    24 gnu++20

    So 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++14 GCC build in CI to prevent silent regressions like this.

  3. KevinEady commented on Jul 31, 2026

    @KevinEady
    Contributor

    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

    "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.

  4. GerjandeGroot commented on Jul 31, 2026

    @GerjandeGroot
    Author

    Thank you, that will clear things up.

  5. linked a pull request that will close this issuedoc: clarify minimum C++ standard #1754on Aug 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions