[Bug]: Cannot compile native modules using nan against Electron v29

[JasonYeMSFT]

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a bug report that matches the one I want to file, without success.

Electron Version

29.1.0

What operating system are you using?

macOS

Operating System Version

14.3.1

What arch are you using?

arm64 (including Apple Silicon)

Last Known Working Electron version

28.2.2

Expected Behavior

My project compiles a few native modules against Electron using nan. The compilation should work.

Actual Behavior

The compilation doesn't work and reports the following error:

npm ERR! ../../nan/nan.h:2548:8: error: no matching member function for call to 'SetAccessor'
npm ERR!   tpl->SetAccessor(
npm ERR!   ~~~~~^~~~~~~~~~~
npm ERR! /Users/my_username/.electron-gyp/Library/Caches/node-gyp/29.1.0/include/node/v8-template.h:806:8: note: candidate function not viable: no known conversion from 'v8::AccessControl' to 'PropertyAttribute' for 5th argument
npm ERR!   void SetAccessor(

Testcase Gist URL

No response

Additional Information

Compiling the same native module code against Node works. Electron 29 uses Node 20.9.0. However, the v8-template.h file that is used to compile the native module to Electron v29 is different from the v8-template.h file that is used to compile the native module to Node v20.9.0.

Electron v29.1.0's v8-template.h at line 800

  void SetAccessor(
      Local<String> name, AccessorGetterCallback getter,
      AccessorSetterCallback setter = nullptr,
      Local<Value> data = Local<Value>(), PropertyAttribute attribute = None,
      SideEffectType getter_side_effect_type = SideEffectType::kHasSideEffect,
      SideEffectType setter_side_effect_type = SideEffectType::kHasSideEffect);
  void SetAccessor(
      Local<Name> name, AccessorNameGetterCallback getter,
      AccessorNameSetterCallback setter = nullptr,
      Local<Value> data = Local<Value>(), PropertyAttribute attribute = None,
      SideEffectType getter_side_effect_type = SideEffectType::kHasSideEffect,
      SideEffectType setter_side_effect_type = SideEffectType::kHasSideEffect);

Node v20.9.0's v8-template.h at line 809

  void SetAccessor(
      Local<String> name, AccessorGetterCallback getter,
      AccessorSetterCallback setter = nullptr,
      Local<Value> data = Local<Value>(), AccessControl settings = DEFAULT,
      PropertyAttribute attribute = None,
      SideEffectType getter_side_effect_type = SideEffectType::kHasSideEffect,
      SideEffectType setter_side_effect_type = SideEffectType::kHasSideEffect);
  void SetAccessor(
      Local<Name> name, AccessorNameGetterCallback getter,
      AccessorNameSetterCallback setter = nullptr,
      Local<Value> data = Local<Value>(), AccessControl settings = DEFAULT,
      PropertyAttribute attribute = None,
      SideEffectType getter_side_effect_type = SideEffectType::kHasSideEffect,
      SideEffectType setter_side_effect_type = SideEffectType::kHasSideEffect);

This discrepancy seems to be the cause of the error. In fact, v8-template.h for Node v21.6.2 also contains the AccessControl argument. My search indicates that the code change was made in this PR in Nov. 2023, which is prior to both the release date of Node v21.6.2 and Electron v29.1.0. I don't know why there would be such discrepancy in their header files. I am opening this issue in the Electron repo instead of the nan repo because Node's header files seem to be keeping the AccessControl argument. The author of "nan" cannot simply change their usage of the API because that would break native modules targeting Node.

[MarshallOfSound]

This is an upstream nan issue, Electron is occasionally on newer versions of V8 than node is. Nan still needs to update their code to support the newer v8 version eventually.

In this case this has already been fixed upstream but has not been released yet. --> nodejs/nan#966

Related though, you should avoid native modules that depend on nan. It is unsafe in general, even more-so in Electron. Native modules should be built depending on napi instead nowadays as it is substantially safer (and doesn't have these v8 drift issues)

[beshkenadze]

@MarshallOfSound How can we avoid using sqlite3?

[ufukomer]

Same here. I had to revert to electron v28.