Code zwischen Code-Knoten teilen

Die Projektdateien eines Code-Knotens gehören genau diesem einen Knoten. Wenn zwei Knoten denselben Klassifizierer, Parser oder dieselbe Formatierungsregel brauchen, liegt Kopieren nahe — und ist falsch: Die Kopien laufen auseinander, und nichts sagt dir, wann.

Die gemeinsame Bibliothek ist der Ort für solche Logik. Sie ist ein lib/-Baum pro Workspace. Jeder Code-Knoten sieht ihn beim Lauf unter /sc/lib/, und repo-sync hält den lib/-Ordner deines Workspace-Repos als einzige Quelle.

Ein gemeinsames Modul anlegen

1. Öffne Einstellungen → Daten & Sync → Gemeinsame Bibliothek.

2. Lege über Neue Datei im Dateibaum eine Datei an und gib einen Pfad relativ zur Bibliothekswurzel an — mail_triage.ts, oder pdf/stage0.py für einen Unterordner. Setze kein lib/ davor; dieses Präfix kommt automatisch dazu.

3. Schreibe das Modul und klicke Speichern.

Im Kopf steht die Zeile Import als für die ausgewählte Datei. Das ist genau der Spezifizierer, den ein Code-Knoten braucht — kopiere ihn, statt einen aus dem Gedächtnis zu tippen: Die beiden Laufzeiten sind sich uneinig darüber, wie ein gültiger Spezifizierer aussieht.

Aus einem Code-Knoten importieren

Die Bibliothek landet unter /sc/lib/, neben der Einstiegsdatei des Knotens unter /sc/main.ts (bzw. /sc/main.py). Das gilt in jedem Modus eines Code-Knotens — inline, script und project —, sodass auch ein Knoten, dessen Quelle in deiner Workflow-YAML steht, ein gemeinsames Modul importieren kann, ohne dass sich sonst etwas ändert.

TypeScript (Deno)

import { classify } from "./lib/mail_triage.ts";

const bucket = classify(subject);

Das führende ./ und die Endung .ts sind beide Pflicht. Deno ergänzt keine Endungen und löst keine nackten Spezifizierer auf lokale Dateien auf — import { classify } from "mail_triage" scheitert also. Das ist der mit Abstand häufigste Fehler beim Portieren von Node-Code.

Python

import lib.pdf_stage0
from lib.pdf_stage0 import classify

kind = classify(raw_bytes)

Die Endung entfällt, Ordner werden zu Punkten: aus pdf/stage0.py wird lib.pdf.stage0. Das funktioniert, weil Python das Verzeichnis des Einstiegs­skripts (/sc) an den Anfang des Importpfads stellt — du brauchst weder eine sys.path-Zeile noch eine __init__.py.

Die eigene Datei des Knotens gewinnt

Enthalten die Projektdateien eines Code-Knotens bereits lib/util.ts, wird diese Datei verwendet und die gemeinsame util.ts nicht darübergelegt. Etwas in die gemeinsame Bibliothek zu legen kann also nie stillschweigend eine Datei ersetzen, die ein Knoten schon hatte.

Das Repo bleibt die Quelle

Mit eingerichtetem repo-sync geht die gemeinsame Bibliothek über den lib/-Ordner deines Workspace-Repos hin und zurück — ohne Hüllendatei und ohne Metadaten-Kopf, sodass die Datei, die du im Diff liest, exakt die Datei ist, die läuft.

• Push schreibt jede gemeinsame Datei nach lib/<Pfad>.
• Pull holt Änderungen zurück und entfernt Dateien, die du im Repo gelöscht hast. Das ist die einzige Stelle, an der ein Pull löscht: Eine gemeinsame Bibliothek, deren Löschungen nicht durchschlagen, ist keine einzige Quelle mehr, sondern ein Zwischenspeicher, der nur wächst.

Eine Datei, die du in der Oberfläche später bearbeitet hast als der eingehende Commit, bleibt erhalten — sie wird weder überschrieben noch entfernt. Das ist dieselbe Last-Write-Wins-Regel wie im übrigen repo-sync.

Grenzen

Dateien pro Workspace	64
Größe pro Datei	256 KiB
Inhalt	Nur Text

Nur-Text ist eine bewusste Entscheidung: Der lib/-Ordner des Repos ist die einzige Quelle dieser Bibliothek, und ein Push schreibt Textdateien. Eine Binärdatei könnte diesen Weg nicht gehen — sie läge in der Datenbank, tauchte in keinem Diff auf und höbe still genau die Zusage auf, für die es die Bibliothek gibt. Lege Binär-Assets stattdessen in die Projektdateien des jeweiligen Code-Knotens.

Gemeinsame Dateien werden nicht getemplatet

Platzhalter wie ${{ steps.… }} und ${{ trigger.… }} werden in der eigenen Quelle eines Code-Knotens ersetzt, in einer gemeinsamen Datei jedoch nicht — sie erreicht den Container genau so, wie sie im Repo steht. Eine Bibliothek wird einmal geschrieben und von vielen Knoten importiert; eine Ersetzung pro Lauf würde dieselbe Datei in jedem Knoten anders verhalten lassen. Übergib Werte, die pro Lauf verschieden sind, als Argumente an deine gemeinsamen Funktionen.

Siehe auch

• Memories verwalten — die andere Workspace-Fläche, die über das synchronisierte Repository hin und zurück geht.
• Runs und Tasks