Node.js kan nu anropa Windows-API:er utan att skriva C++

Sedan 27 juli 2026 finns det ett sätt att nå Windows inbyggda API:er direkt från JavaScript, utan att skriva native-kod. Microsoft släppte då sin WinRT-projektion för Node.js i public preview. Den installeras med npm, genererar JavaScript-wrappers automatiskt från Windows SDK:s metadata och kräver varken node-gyp, MSVC eller Python på utvecklarmaskinen.

Enkelt uttryckt: den som bygger en Electron-app och vill använda Windows notifikationssystem, filväljare eller lokala AI-modeller behöver inte längre kunna C++ eller C#.

Tidigare kostade ett enda API-anrop en hel byggkedja

Så här såg det ut innan. Ville du komma åt ett Windows-API från Node.js fanns två vägar, båda dyra.

Den ena var ett C++-addon. Då behövde du node-gyp, MSVC, Python och Windows SDK installerat, plus wrapper-kod för varje enskilt API du ville nå. Byggde du för Electron tillkom en CI-matris eftersom addonet måste kompileras om per Electron-version. Den andra vägen var ett C#-addon, vilket krävde .NET SDK och ett csproj-byggsteg i pipelinen.

Båda innebar att ett JavaScript-team behövde kompetens i ett andra språk för att göra en sak: skicka en notis.

Generatorn läser metadata, inte en fast API-lista

Skillnaden mot tidigare projektioner sitter i ordet dynamisk. C++/WinRT, C#/WinRT, windows-rs och PyWinRT är alla statiska: någon har bestämt vilka API:er som ingår och de ingår.

Den här läser i stället Windows metadatafiler, `.winmd` och genererar JavaScript-wrappers plus TypeScript-deklarationer utifrån vad som faktiskt står där. Kommer ett nytt kompatibelt API i en framtida SDK-version räcker det att köra generationen igen mot den nya metadatan. Ingen väntan på att någon ska hinna skriva bindningar.

Vid körning gör en delad runtime resten. Paketet `@microsoft/dynwinrt` dispatchar alla anrop, vilket betyder att du inte får ett nytt native-addon per API du använder. Ett runtime, valfritt antal API:er. Koden och dokumentationen finns publikt på GitHub och stödet omfattar x64 och arm64.

Tre paket och ett kommando

Uppsättningen består av tre npm-paket. `@microsoft/dynwinrt` är runtime, `@microsoft/dynwinrt-codegen` läser metadatan och genererar wrappers och `@microsoft/winappcli` är CLI-verktyget som sätter ihop det hela.

Kommandot `npx winapp init . –use-defaults –add-js-bindings` skapar en `Package.appxmanifest` och lägger genererad output under `.winapp/bindings/`. Därifrån importerar du som vilket JavaScript-modul som helst, med typerna på plats i editorn.

AI-funktionerna är den intressanta delen

De API-kategorier som stöds är genomgående icke-grafiska, alltså inget UI. I praktiken tre grupper.

On-device AI är den tyngsta: textgenerering, sammanfattning, omskrivning, text-till-tabell, bildbeskrivning, textökning, bildskalning, objektextrahering och objektborttagning samt Windows ML-modeller. Det är funktioner som annars kostar API-anrop mot en molntjänst men som här körs lokalt på användarens maskin.

Sedan finns app- och innehållsfunktioner: notifikationer, fil- och mappväljare, lagring, bilddekodning och rich clipboard. Och en system- och enhetsgrupp med nätverk, sensorer, globalisering och kryptografi.

För ett svenskt utvecklarteam som bygger ett internt verktyg i Electron är den lokala AI-delen den konkreta vinsten. Sammanfattning av dokument utan att texten lämnar datorn är en annan sak att förhålla sig till dataskyddsmässigt än sammanfattning via ett externt API. Windows Electron-galleri använder redan den här projektionen.

Låsningsfrågan går inte att avfärda

Det uppenbara invändningen: det här är Windows-API:er och de fungerar bara på Windows. En Electron-app som bygger sin AI-funktionalitet på lokala Windows-modeller får ingenting av det på macOS eller Linux.

Microsoft beskriver satsningen som ett sätt att öppna plattformen, inte stänga in någon. Men riktningen är svår att missläsa. Genom att göra Windows AI-funktioner tillgängliga för det största utvecklarspråket på webben blir Windows en mer attraktiv primärplattform för desktop-appar, precis när molnleverantörerna slåss om vem som ska köra företagens AI-arbetsbelastningar.

Två saker försvinner inte heller med det här: paketidentitet och signering. Vill du distribuera en app som använder Windows-specifika funktioner behöver du fortfarande gå igenom den processen. Verktygen gör API-anropen enkla, inte distributionen.

Och preview är preview. `@microsoft/dynwinrt` är inte produktionsklart i skrivande stund, vilket betyder att API-ytan kan ändras innan en stabil release. Bygger du något du ska leverera i höst är det rimligt att prototypa med det, inte att bygga hela produkten på det.

FAQ

Behöver jag Visual Studio installerat?

Nej. Hela poängen med den dynamiska projektionen är att byggkedjan flyttar bort från utvecklarmaskinen. Du installerar paketen med npm och kör CLI-kommandot.

Fungerar det med vanlig Node.js eller bara Electron?

Projektionen riktar sig till Node.js och Electron är det mest uppenbara användningsfallet eftersom Electron kör Node under huven. Windows Electron-galleri använder den redan.

Är det möjligt att nå UI-API:er som WinUI

Nej, stödet gäller icke-grafiska API:er. Notifikationer och filväljare är systemdialoger, inte fönsterritande komponenter. För gränssnittet ritar du fortsatt i HTML och CSS, vilket är rimligt givet att du valde Electron från början.

Vad händer om Microsoft slutar underhålla det?

Det är en reell risk med allt i preview. Paketen är open source på GitHub, vilket åtminstone betyder att koden finns kvar och går att forka. Men en övergiven runtime som ska följa Windows SDK-utvecklingen åldras snabbt.

Nästa milstolpe att bevaka är när paketen lämnar preview och Microsoft säger något om bakåtkompatibilitet. Innan dess är det ett verktyg att prova, inte att luta en produktionsapp mot. För den som vill förstå hur JavaScript-ekosystemet i övrigt hanterar den här sortens beroenden finns en genomgång av varför beroenden från Git löser färre problem än de skapar och för AI-delen specifikt en bakgrund om autonoma AI-agenter som eget lager i infrastrukturen.