Please release missing native build for Arm64 armv=8?

ironsheep commented 1 month ago

SerialPort Version

12.0.0

Node Version

18.18.2

Electron Version

28.2.8

Platform

platform=win32 arch=arm64 runtime=electron abi=119 uv=1 armv=8 libc=glibc

Architecture

Arm64 armv=8

Hardware or chipset of serialport

N/A

What steps will reproduce the bug?

I have SerialPort built into my VSCode extension. It runs well on many platforms. I have a Mac Studio - Apple M2 Ultra, 192GB running macOS Sonoma 14.5. I'm running Windows 11 in Parallels Desktop for Max (Pro Edition) v19.4.0

I install the spin2 extension into VSCode and I open a spin2 file. The extension crashes with the error shown in "What happens" below. It appears that one of the supporting binaries is not available for download: No native build was found for platform=win32 arch=arm64 runtime=electron abi=119 uv=1 armv=8 libc=glibc node=18.18.2 electron=28.2.8

How can we get this native build added to the distribution?

This is one of my primary development platforms (I am using Windows 10, Linux raspiOS, macOS Sonoma, and Windows 11 in Parallels) for my development of this extension.

Here is the unreleased version of the extension that exhibits the crash... spin2-2.2.19.vsix.zip

What happens?

This is the crash output from the Spin2 Extension Host log

2024-05-23 21:02:53.368 [info] ExtensionService#_doActivateExtension IronSheepProductionsLLC.spin2, startup: false, activationEvent: 'onLanguage:spin2'
2024-05-23 21:02:53.552 [error] Activating extension IronSheepProductionsLLC.spin2 failed due to an error:
2024-05-23 21:02:53.552 [error] Error: No native build was found for platform=win32 arch=arm64 runtime=electron abi=119 uv=1 armv=8 libc=glibc node=18.18.2 electron=28.2.8
    loaded from: c:\Users\stephen\.vscode\extensions\ironsheepproductionsllc.spin2-2.2.19\client\node_modules\@serialport\bindings-cpp
    at Function.load.resolve.load.path (c:\Users\stephen\.vscode\extensions\ironsheepproductionsllc.spin2-2.2.19\client\node_modules\node-gyp-build\node-gyp-build.js:60:9)
    at load (c:\Users\stephen\.vscode\extensions\ironsheepproductionsllc.spin2-2.2.19\client\node_modules\node-gyp-build\node-gyp-build.js:22:30)
    at Object.<anonymous> (c:\Users\stephen\.vscode\extensions\ironsheepproductionsllc.spin2-2.2.19\client\node_modules\@serialport\bindings-cpp\dist\load-bindings.js:11:46)
    at Module.o._compile (c:\Users\stephen\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\loader.js:4:1271)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1326:10)
    at Module.load (node:internal/modules/cjs/loader:1126:32)
...

What should have happened?

It should locate the native build binary and continue to run as normal

Additional information

If you need anything else you can reach me at stephen@ironsheep.biz

iamshiv4m commented 3 weeks ago

@ironsheep , is this fixed? i am getting the same error

Komodood commented 1 week ago

Same problem

ironsheep commented 1 week ago

NOTE: While this describes how to distribute the prebuilt files correctly, the Windows arm64 package is STILL NOT PRESENT in the list of prebuilt binaries!

I just discovered tonight that, after a bit of studying the node-gyp-build/node-gyp-buid.js code that is throwing the not-found exception, I was able to determine that it is looking for the files in a couple of 'expected' locations.

So now this appears to be a packaging issue. The platform binaries are prebuilt. But the runtime loader (file mentioned above) needs to find them in one of the expected locations. I had to create a receiving directory that my extension includes in the package. I then had to copy the prebuilt .node files into this new location. I added a new entry in my package.json "scripts" section:

"makeprebuild": "mkdir -p ./client/prebuilds && cp -pr ./client/node_modules/@serialport/bindings-cpp/prebuilds/* ./client/prebuilds/"

... and then modified my prebuild script to run this new step by appending && npm run makeprebuild:

    "prebuild": "npm run compile && npm run compile:grammar && npm run makeprebuild",

My extension distributes both a ./client/out/extension.js file and also a ./server/out/server.js' file. It now also distributes this new./client/prebuilds/` folder as well.

I had to add:

!client/prebuilds/**/*

... to my .vscodeignore file to get this new directory into my packaged extension.

Now this is all working for me!

Your solution may not be exactly the same since not everyone is distributing a ./server component. But this should guide you in crafting your solution.

ironsheep commented 1 week ago

AUGH! This only solved part of my distribution problem in that win32-arm64/ is NOT one of the prebuilt platform binaries. I need win32-arm64/ to run Windows 11 in Parallels Desktop on a Mac Sudio M2 Ultra-based machine.

The following are there tho'

android-arm/  
android-arm64/  
darwin-x64+arm64/  
linux-arm/  
linux-arm64/  
linux-x64/  
win32-ia32/  
win32-x64/

Komodood commented 1 week ago

AUGH! Это решило только часть моей проблемы с дистрибуцией, поскольку win32-arm64/ НЕ является одним из готовых двоичных файлов платформы. Мне нужен win32-arm64/ для запуска Windows 11 в Parallels Desktop на машине Mac Sudio M2 Ultra.

Однако есть и следующее:
android-arm/  
android-arm64/  
darwin-x64+arm64/  
linux-arm/  
linux-arm64/  
linux-x64/  
win32-ia32/  
win32-x64/

so u mean, this list of archs was builded?

ironsheep commented 1 week ago

Yes, these are all found in node_modules/@serialport/bindings-cpp/prebuilds

serialport / node-serialport