Endringer i JavaScript-koden i RoomOS-makroer

Vi har oppdatert maskineriet som kjører makroene på RoomOS, og som et resultat av disse oppdateringene vil noen JavaScript-konvensjoner og funksjoner ikke lenger være tilgjengelige for makroene. Spesielt er CommonJS-relaterte funksjoner ikke lenger tilgjengelige. Noen vanlige eksempler på kode som trenger omskriving er:

1. krever(), inkludert:
   • require('xapi') - må skrives om til standard ECMAScript-import . F.eks., const xapi = require('xapi') endret til import xapi fra 'xapi'
   • require.main
2. modul, inkludert:
   • modul.exports - må skrives om til standard ECMAScript-eksport
   • module.name - bør erstattes med _main_module_name()

Hvordan slås dette av og på?

Disse endringene trer i kraft når xConfiguration Macros EvaluateTranspiled byttes fra True til False. Denne innstillingen har vært til stede i lang tid, og endringen rulles ut ved å endre standardverdien i nye utgivelser fra True til False.

Hvis makroer brytes på denne endringen, er eksplisitt å sette veksleknappen tilbake (xConfiguration Macros EvaluateTranspiled: True) en kortsiktig løsning for å få dem til å fungere som før. Vær imidlertid oppmerksom på at dette bare er en midlertidig løsning: Denne bryteren vil forsvinne etter en overgangsperiode.

På samme måte, på eldre RoomOS-versjoner kan denne endringen testes uten oppgradering ved å sette bryteren til False.

Merknad: Hvis en makro er lagret på enheten mens veksleknappen er Usann , og du senere bestemmer deg for å TURN veksle tilbake til Sann , kan det være nødvendig ålagre disse makroene på nytt i makroredigeringsprogrammet.

Når trer disse endringene i kraft?

Standardverdien for EvaluateTranspiled-bryteren ble endret til False fra og med RoomOS May 2025 (11.28), noe som betyr at enheter vil bytte som standard når de oppgraderes. I samme versjon er transpilasjonstrinnet når du lagrer makroer via XAPI, deaktivert som standard. Hvis transpilering kreves gjennom XAPI, må kommandoalternativet for transpilering settes eksplisitt til sann.

Fra og med RoomOS juli 2025 (11.30) vises en diagnose når bryteren er satt til True. Det vil fortsatt fungere som før.

Fremover vil bryteren bli fjernet helt, og enheten vil oppføre seg som om den var satt til False. Vi tar sikte på å rulle ut denne endringen i november 2025. Denne datoen kan endres når vi ser hvor mange av kundene våre som kan oppdatere makroene sine, men tidslinjen måles i måneder, ikke år. De nøyaktige datoene vil bli publisert her og i utgivelsesnotatene til de relevante RoomOS-utgivelsene.

Alle kunder som, til tross for vår beste innsats for å prøve å varsle og informere om endringene, ser at makroene deres mislykkes når endringene er permanent på plass i RoomOS, kan fortsatt bruke (opptil) 6 måneders forsinket programvareoppdatering som leveres gjennom Control Hub for skyregistrerte enheter for å forsinke endringen.

Hvorfor er dette nødvendig? Tekniske detaljer

Hoveddriveren for denne endringen er at vi har oppdatert JavaScript-motoren til å bruke QuickJS, som fungerer som en moderne, oppdatert JavaScript-kjøretid for innebygde systemer. Etter det, siden det ikke lenger er nødvendig med en moderne JavaScript-motor, fjerner vi nå støtten for transpilering av JavaScript. Fjerning av det ekstra trinnet med å transpilere all kode reduserer lastetiden når du distribuerer og kjører kode, samt reduserer kompleksiteten i plattformen.

JavaScript-motorbryteren styres av xConfiguration Macros QuickJSEngine: Av endret til På. Denne endringen ble rullet ut i RoomOS desember 2023 (11.11), og vi planlegger å fjerne denne konfigurasjonsbryteren på samme tidslinje som EvaluateTranspiled.

Vi gjør disse endringene for å sikre at RoomOS yter maksimalt, og at vi kan hjelpe deg med å skalere distribusjonen av JavaScript-utvidelser på en effektiv og sikker måte.

Les mer om makroer på roomos.cisco.com.