Bei mir haben sich mittlerweile über 100 Skripte angesammelt und es kommt immer wieder mal noch was dazu.
Und auch hier, ja, mir ist bewusst das 5 Instanzen vom Javascript-Adapter speichermäßig „teuer“ erkauft sind. Daher auch der eigene Pi als Slave. Performanceprobleme hatte ich dadurch bis dato noch keine, zumindest nicht bemerkt.

Was für mich nicht sinnvoll war / ist, ist mehrfach verwendeten Code zu kopieren oder parallel in Skripten zu haben, das macht aus meiner Sicht irgendwann die Wartung oder Ausrollung von Erweiterungen fast unmöglich.

Die Klassen und Module im großen Stil in global zu verpacken ist für mich auch keine sinnvolle Option. Auch wenn es vermutlich nicht soviel Performance kostet. Ich habe auch mehrere Funktionen die ich mehr oder wenige in jedem Skript in irgendeiner Art verwende, z.B. erweiterte Logging-Funktionen, die habe ich auch im global in zwei Closures zusammengefasst. Mir gefällt dabei aber nicht, das bei einer kleinen Änderung in einem globalen Skript alle Skripte in allen Instanzen neu starten und weiters auch nicht, dass ich da im Hauptskript irgendwas unsichtbar im Vorbau geschrieben habe (das ist aber eine persönliche Befindlichkeit).
Aber als Beispiel, ich habe ein Modul mit Funktionen zu diversen Farbwertumrechnungen. Diese benötige ich in 7 von den etwas über 100 Skripten. Dafür jetzt diese in global überall „mitzuschleppen“ widerstrebt mir irgendwie.

Aus diesem Grund ist für mich die Einbindung von Modulen und Klassen über require die sinnvollste Lösung.
Vor allem weil ich

• alles an einem Platz im Javascript-Adapter habe,
• nicht mit externen Files herumhantieren muss,
• im Hauptskript immer genau sehe was ich über require eingebunden habe,
• die Skripte aus meiner Sicht besser strukturieren und aufteilen kann
• und auch die Sicherung mit allen Hauptskripten einfach mitläuft.

(und ja, das bietet global im Wesentlichen auch)
Aber wie geschrieben für mich. Ich denke es muss jeder für sich selbst die praktikabelste Lösung finden.

@legro [sagte]: Leider bläht mir dieses Konzept mein System gewaltig auf, sodass ich dieses Konzept nicht (mehr) verwende.

Globale Skripte dienen häufig verwendeten eigenen Funktionen. Das Kopieren der globalen Funktionen in ein (nicht globales) Skript erfolgt unmittelbar vor dem Kompilieren. Es werden nur die Funktionen kompiliert, die auch aufgerufen werden (sie werden an der Stelle des Aufrufs eingefügt). Somit erfolgt kein Aufblähen des Systems durch viele globale Funktionen.

Anmerkung: Funktionen in Javascript sind keine Unterprogramme. Es gibt weder Bibliotheken noch den dafür erforderlichen Linker.

@legro sagte:
Nur ist nach einem ersten Durchlesen mein Eindruck, dass das Ganze nicht wirklich problemlos funktioniert - vor allem nicht auf Dauer, da immer wieder Änderungen an diesem System vorgenommen werden. Oder schätze ich dies falsch ein?

Das Problem ist hier einfach die Sinnhaftigkeit.

Globale Skripte z.B. machen weder den Javascript-Adapter langsamer, noch verbrauchen sie viel Speicher. Das ist nur ne Kopfsache.

Ich mal nachgeguckt und da ist bei mir ein 7000 Zeilen lange Map im globalen Ordner die ich nicht mehr brauche (hab nen Adapter dafür geschrieben)

Ohne das globale Skript verbrauchen die beiden Javascript-Adapter-Instanzen zusammen ca. 590 MB, mit aktiviertem globalen Skript ca. 609 MB. Beides ca. 2 Minuten nach Restart.

Ich hab rund 50 laufende Skript - das globale Skript hat 234368 Zeichen: 50 * 234kb =11 700 KB-> 11,7 MB kommt also hin.(davon ausgehend das es 1 Byte pro Zeichen sind - mit tausend gerechnet)

Das ich 2 Javascript-Instanzen nutze kostet mich ca. 150MB extra.

Wenn ich viele Standardfunktion hätte, würde ich mir eine globale statische Klasse anlegen und dort den Kram rein machen. Werde ich aber nicht machen, da ich dann die Skripte nicht mehr einfach weitergeben kann.

Das einzig was etwas lästig ist, ist dass erforderliche Neustarten der Javascript-Instanz nach einer Änderung in einem Modul. Das ist aber bei den globalen Skripten im Wesentlichen ja auch so.
Dies ist auch mit einer der Gründe warum bei mir der Javascript-Adapter mit mittlerweile 5 Instanzen auf einem Raspi 4 (8 GB) als Slave läuft. Damit kann ich das halbwegs gut strukturieren, dass beim jeweiligen Instanzneustart nicht alle Skripte immer neu starten.
Was bei der Aufteilung auch problemlos funktioniert ist, dass das Hauptskript (das Skript das require aufruft) nicht in der selben Instanz sein muss wie das Modul, das funktioniert kreuz und quer.

Danke für den Hinweis.

Wenn ich das richtig verstanden habe, stellt die Option require .. genau das bereit, was ich mir wünsche: eine Library-Funktion.

Nur ist nach einem ersten Durchlesen mein Eindruck, dass das Ganze nicht wirklich problemlos funktioniert - vor allem nicht auf Dauer, da immer wieder Änderungen an diesem System vorgenommen werden. Oder schätze ich dies falsch ein?

Vorab erst einmal vielen Dank für deine ausführliche Antwort.

Die bisher zu diesen Themen geführten Diskussionen führten leider in meinen Augen nicht zu praktikablen Lösungen. Es blieb letztendlich mehr oder weniger alles beim Alten. Daher habe ich wenig Hoffnung auf tiefgreifende Änderungen.

Meine Einsicht: Es ist wohl auch ein wenig vermessen, von einem System zur Hausautomatisierung eine Entwicklungsumgebung zu erwarten.

Debugger ..

Das dürfte daher ein Wunschtraum bleiben. Hierzu behelfe ich mich ausschließlich mit (Test)Ausgaben in die Console. Hinsichtlich der Verwendung von visual studio code blieb es bei mir leider bloß bei unglücklichen Versuchen.

Library ..

Hier hoffe ich jedoch darauf, dass man eine - doch wohl leicht zu realisierende Art - Include-Technik realisieren könnte: Am Beginn eines Skriptes gibt man an, welche globalen Skripte eingebunden werden sollen.

Hier ist meine derzeitige Notlösung: Ich erstelle in einem Verzeichnis (Library)Skripte mit Funktionen, die ich in mehreren (Anwendungs)Skripten benötige. Dazu kopiere ich das jeweilige (Library)Skript manuell die (Anwendungs)Skripte. Auf diese Weise kann ich sogar Variablen in diesen eingebunden Skripten verwenden.

Aufteilen von Skripte

da gibt e mittlerweile mehrere threads. Eine so richtig gute standardlösung gibt es nicht, da das ablegen von extra Dateien im DAteisystem immer etwas schwierig ist.

Die beste Lösung ist glaube ich die Funktionen auf verschiedene Skripte aufzuteilen und die Funktionen über das Messagingsystem (messageToAsync,onMessage) aufzurufen. Ein Besipiel siehst du hier
https://forum.iobroker.net/topic/84000/skript-aufteilen-möglich/13?_=1775167478022

Debugger

gibt/gab es schon (so ein käferknopf, den ich aber jetzt nicht mehr sehe), aber der ist glaube ich nicht wirklich gut zu bedienen.
Wenn du, allerdings mit kleinen Einschränkungen, debuggen willst, dann verwende dazu vscode. für vscode gibt es auch eine extention die dir die scripte hin und her synchronisiert.
Allerdings stehen dir in vscode die iobroker funktionen nicht zur Verfügung. Also setState ist dort unbekannt.
Ich behelfe mich da immer mit stub-funktionen, die ich am Ende meines Skripts hinzufüge, also sowas wie

//vscode stub functions for iob
function on(/* event, callback */) { }
function setState(/* id, value, ack */) { }
function log(/* msg, level */) { }
function schedule(/* event, callback */) { }

Diese Funktionen machen einfach nichts. Wenn du zum testen dann das doch mal brauchst, kannst du das durch extra code einfach simulieren

Am Beispiel von getState würde das dann so aussehen:
Als erstes holt man sich den Rückgabewert von getState in einem skript im iobroker

log(JSON.stringify(getState("0_userdata.0.val1")));

Das erzeugt dann im log den folgenden Eintrag

{"val":"123","ack":false,"ts":1768518884892,"q":0,"from":"system.adapter.admin.0","user":"system.user.admin","lc":1768518884892}

Den kopiert man
und fügt ihn in eine stubfunktion wie folgt ein

function getState(id) {
  if (id === "0_userdata.0.val1") {
    return JSON.parse(
      '{"val":"123","ack":false,"ts":1768518884892,"q":0,"from":"system.adapter.admin.0","user":"system.user.admin","lc":1768518884892}',
    );
  }

und schon hat man seine Stummelfunktion für getState, mit der man dann seine Skripte im iobroker auch debuggen und testen kann.