Building with Electron 13 does not work on Windows

[andiliu-gh]

It seems as if building with Electron 13 is broken on Windows due to this: electron/electron#29893

Error from neon:

    neon.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: class std::shared_ptr<class v8::BackingStore> __thiscall v8::ArrayBuffer::GetBackingStore(void)" (__imp_?GetBackingStore@ArrayBuffer@v8@@QAE?AV?$shared_ptr@VBackingStore@v8@@@std@@XZ) referenced in function _Neon_ArrayBuffer_Data [C:\Users\andyl\-\target\release\build\neon-sys-ab7d83299aae5b27\out\native\build\neon.vcxproj]
    C:\Users\-\target\release\build\neon-sys-ab7d83299aae5b27\out\native\build\Release\neon.node : fatal error LNK1120: 1 unresolved externals [C:\Users\-\target\release\build\neon-sys-ab7d83299aae5b27\out\native\build\neon.vcxproj]

I think it's cause neon uses nan or that it builds with msvc...? So the header signature is mismatched. The Electron issue link above mentions building with libc++ to avoid this issue or to replace nan.h w N-API?

[kjvalencik]

I would be willing to merge a fix for this, but none of the core devs are Windows developers which would make this difficult.

However, Neon with the napi backend (the default when creating a project with npm init neon my-project) does not have this issue. That backend already uses Node-API (formerly N-API).

Since the legacy backend (neon-sys) is no longer being actively developed, it is unlikely that this will be fixed.

I'm happy to chat in our Slack channel about possible fixes, but I most likely won't have chance to work on it myself.

A couple possible solutions:

• (Simple) If you don't need ArrayBuffer, would be to put it behind a feature flag so that users can disable it for Electron compatibility
• (Complicated) Convert ArrayBuffer to Buffer and use their content APIs

[andiliu-gh]

Oh I was totally unaware that we were still using the legacy backend. I assumed that since we were updated that it would be backed by the napi backend. I also asked my co-worker regarding that and that's what he concluded as well. I'll get back to you if we're still facing issues w the napi backend!

[kjvalencik]

@andiliu-gh Let me know! We chose not to change the default backend on existing projects since it would needlessly cause breaking changes. We may add a compiler warning in the future (or default to no backend). Instead, new projects will default to the napi backend.

There are a bunch of breaking changes between the backends. The migration guide may be helpful.

[kjvalencik]

@andiliu-gh I still highly suggest switching to the napi backend, but if you would like to try it, this may fix the issue:

#785