nan deprecation warnings with Node.js 24

[agracio]

Newly released Node.js v24 is based on v8 13.6 which introduces new warnings during native module compilation.

nan.h(1173,27): warning C4996: 'v8::String::WriteUtf8': Use WriteUtf8V2 instead

nan.h(2423,18): warning C4996: 'node::Encode': was declared deprecated

The exact line numbers are conditional and there is more code that uses deprecated methods.

Although it does not affect my native node modules there is also a reported error for some modules when compiling against Node.js v24 #996 as well as this potential issue #995

It appears that Node.js team is now pushing to update v8 engine regularly as there is already a PR to bump it to 13.7 in main. The warnings may soon become errors with the release of Node.js v25.

[i5ting]

when support node v24？

[Tiuipuv]

While the first half of this issue has been fixed, the second half still remains:

warning: ‘v8::Local<v8::Value> node::Encode(v8::Isolate*, const char*, size_t, node::encoding)’ is deprecated: Use TryEncode(...) instead

It has existed since node::Encode deprecation warning was merged and backported across versions v25, v24, and has a tag for v22 backport:

• src: improve StringBytes error handling node#57706

@agracio can you re-open this issue?

[agracio]

This is not a real issue and does not require a fix.

node.h

// The original Encode(...) functions are deprecated because they do not
// appropriately propagate exceptions and instead rely on ToLocalChecked()
// which crashes the process if an exception occurs. We cannot just remove
// these as it would break ABI compatibility, so we keep them around but
// deprecate them in favor of the TryEncode(...) variations which return
// a MaybeLocal<> and do not crash the process if an exception occurs.
NODE_DEPRECATED(
    "Use TryEncode(...) instead",
    NODE_EXTERN v8::Local<v8::Value> Encode(v8::Isolate* isolate,
                                            const char* buf,
                                            size_t len,
                                            enum encoding encoding = LATIN1));

// Warning: This reverses endianness on Big Endian platforms, even though the
// signature using uint16_t implies that it should not.
NODE_DEPRECATED("Use TryEncode(...) instead",
                NODE_EXTERN v8::Local<v8::Value> Encode(v8::Isolate* isolate,
                                                        const uint16_t* buf,
                                                        size_t len));

The methods will not be removed from future Node.js or Electron releases and as noted in comment removing it would break compatibility.
Additionally it does not track between specific v8 versions because it is part of node.h file meaning there is no clear way to create a PR that uses different methods based on v8 version as it is usually done.
Adding TryEncode to nan would be nice but as I said it is impossible to make this change based on v8 version.

It would be possible to add TryEncode and mark Encode as deprecated based on Node.js version but since it is not a real issue I doubt a PR would get any tractions.

Usually only breaking changes get any real attention, there is likely to be one in v8 14.4

[kkoopa]

It might be possible to tie it to NODE_MODULE_VERSION if that was updated in the same release.

…

On Tue, Dec 2, 2025, 00:08 agracio ***@***.***> wrote: *agracio* left a comment (nodejs/nan#998) <#998 (comment)> This is not a real issue and does not require a fix. node.h // The original Encode(...) functions are deprecated because they do not// appropriately propagate exceptions and instead rely on ToLocalChecked()// which crashes the process if an exception occurs. We cannot just remove// these as it would break ABI compatibility, so we keep them around but// deprecate them in favor of the TryEncode(...) variations which return// a MaybeLocal<> and do not crash the process if an exception occurs.NODE_DEPRECATED( "Use TryEncode(...) instead", NODE_EXTERN v8::Local<v8::Value> Encode(v8::Isolate* isolate, const char* buf, size_t len, enum encoding encoding = LATIN1)); // Warning: This reverses endianness on Big Endian platforms, even though the// signature using uint16_t implies that it should not.NODE_DEPRECATED("Use TryEncode(...) instead", NODE_EXTERN v8::Local<v8::Value> Encode(v8::Isolate* isolate, const uint16_t* buf, size_t len)); The methods will not be removed from future Node.js or Electron releases and as noted in comment removing it would break compatibility. Additionally it does not track between specific v8 versions because it is part of node.h file meaning there is no clear way to create a PR that uses different methods based on v8 version as it is usually done. Adding TryEncode to nan would be nice but as I said it is impossible to make this change based on v8 version. — Reply to this email directly, view it on GitHub <#998 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA7JXKPIF4AVLTUVTEA67TD37S35FAVCNFSM6AAAAAB4Y24FDOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKOJZGE3DSMJWGM> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[agracio]

For node 24 it has NODE_MODULE_VERSION 137 and NODE_MAJOR_VERSION 24. nan.h uses either one or the other in code so something like NODE_MAJOR_VERSION >= 24 will work.

I can create PR or do you want to look at it yourself, documentation will have to be updated and I an very familiar with the process.

[kkoopa]

Please do if you can. I have a lingering concern about how conditioning on NODE_MODULE_VERSION might impact something like Electron, but I cannot see why one would claim this NODE_MODULE_VERSION while not including said function, so it should be fine.

…

On Tue, Dec 2, 2025, 06:09 agracio ***@***.***> wrote: *agracio* left a comment (nodejs/nan#998) <#998 (comment)> For node 24 it has NODE_MODULE_VERSION 137 and NODE_MAJOR_VERSION 24. nan.h uses either one or the other in code so something like NODE_MAJOR_VERSION >= 24 will work. I can create PR or do you want to look at it yourself, documentation will have to be updated and I an very familiar with the process. — Reply to this email directly, view it on GitHub <#998 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA7JXKNAMARZSRZCNAU5EJL37UGF3AVCNFSM6AAAAAB4Y24FDOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMMBQGA4TSOBWGM> . You are receiving this because you commented.Message ID: ***@***.***>

[agracio]

Electron has node_version.h, node.h and all other node related header files. Each Ealectron release always has the same major node version.

Can you point me to what documentation needs to be updated?

[kkoopa]

Doc wise, should be this file https://github.com/nodejs/nan/blob/main/doc/string_bytes.md `make doc` should then update README.md from this.

…

On Tue, Dec 2, 2025, 06:29 agracio ***@***.***> wrote: *agracio* left a comment (nodejs/nan#998) <#998 (comment)> Electron has node_version.h and node.h because and all other node related header file. Each Ealectron release always has the same major node version. Can you point me to what documentation needs to be updated? — Reply to this email directly, view it on GitHub <#998 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA7JXKLA5QNWXG7EHCMQFIL37UISJAVCNFSM6AAAAAB4Y24FDOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMMBQGEZTOMJZGQ> . You are receiving this because you commented.Message ID: ***@***.***>

[agracio]

Since node::Encode() is deprecated but remains in code it will still throw those warning. PR will only add wrapper around node::TryEncode()

[kkoopa]

No, it should be automated and I do not remember it requiring any more steps. I can check in a bit.

…

On Tue, Dec 2, 2025, 15:54 agracio ***@***.***> wrote: *agracio* left a comment (nodejs/nan#998) <#998 (comment)> Adding new <a name="api_nan_try_encode"></a> in string_bytes.md does not create a new entry in README after building docs. Is adding a new API entry a manual process? — Reply to this email directly, view it on GitHub <#998 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA7JXKO3S6S7WTLX6OWDXG337WK2DAVCNFSM6AAAAAB4Y24FDOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMMBSGE4TMMRSG4> . You are receiving this because you commented.Message ID: ***@***.***>

[agracio]

#1005

[agracio]

On closer inspection Electron defines correct NODE_MAJOR_VERSION but for some reason overrides NODE_MODULE_VERSION with different values.
Using NODE_MAJOR_VERSION was the right choice.