Il packaging di release come workflow ripetibile
Rubra Packager è una workstation desktop Windows per la parte meno glamour della pubblicazione di un gioco web: prendere un progetto statico fidato, verificare che il pacchetto sia coerente e produrre una build di destinazione senza ripetere ogni volta gli stessi passaggi manuali.
Il progetto vive nel repository Rubra-Composer L'attuale baseline del sito è v0.5.0 — Sviluppo attivo.
Cosa copre la v0.5.0
Registra i progetti una volta
Lo scaffale Projects memorizza una cartella sorgente insieme al profilo di packaging e ai metadata di release. Profili come Arena Rubra, Generic Web Game e Generic HTML App definiscono percorsi richiesti, impostazioni predefinite del target e regole di esclusione FULL/LITE.
Questo mantiene la policy di packaging fuori dal sorgente del gioco e rende più facile riprodurre build successive.
Preflight prima del packaging
Una build dovrebbe fallire presto, e per il motivo giusto.
Il preflight analizza la variante selezionata, segnala i file inclusi ed esclusi, stima la dimensione del pacchetto e separa gli errori bloccanti dagli avvisi. I riferimenti statici HTML/CSS, gli import di moduli JavaScript locali e gli asset statici new URL(..., import.meta.url) possono essere controllati direttamente; i percorsi dinamici generati a runtime non vengono indovinati.
Output eseguibile Windows
Il workspace Windows prepara un eseguibile desktop monofile usando lo stack di packaging Windows del progetto. Nome dell'applicazione, profilo, variante e icona personalizzata restano visibili prima dell'avvio della build.
Il repository sorgente documenta il percorso Windows come pacchetto PyInstaller + PyWebView, non come generico convertitore Python-to-EXE.
Output Android APK e AAB
Il packaging Android aggiunge una toolchain separata: Java, Android SDK, Node.js/npm e il percorso di build Gradle/Capacitor.
L'interfaccia v0.5.0 espone output Android orientati a debug/release, selezione APK/AAB, configurazione dell'icona launcher e campi per la firma release. Questi controlli sono volutamente separati dal percorso Windows, così i requisiti di piattaforma restano visibili.
Layout sorgente statici supportati
Rubra Packager riconosce un index.html alla radice o comuni cartelle di output statico, tra cui:
dist/build/out/.output/public/- Gatsby
public/quando viene rilevato Gatsby - stile Angular
dist/<project>/browser/
Il confine è intenzionale: un progetto basato su framework deve produrre un vero index.html. Rendering server-side, API backend e route dinamiche sono fuori dall'attuale scope di packaging.
La fiducia fa parte del design del prodotto
A volte il sorgente richiesto non è già compilato. Rubra Packager può quindi invocare npm install e npm run build, ma gli script dei pacchetti sono codice eseguibile.
L'interfaccia richiede quindi una scelta esplicita di fiducia prima dell'esecuzione del sorgente. L'avviso non è decorativo: fa parte del modello di release.
Perché costruirlo invece di usare un altro script usa-e-getta?
Arena Rubra e i più piccoli esperimenti web GVibeDev hanno richiesto ripetutamente le stesse operazioni: individuare un output statico, validare gli asset richiesti, impacchettare la variante corretta, configurare le icone, compilare per un target e verificare l'artefatto risultante.
Rubra Packager trasforma questo lavoro ripetuto di release in un workflow visibile e ispezionabile:
Registra → Preflight → Correggi → Build → Verifica
L'obiettivo non è nascondere il packaging dietro un pulsante magico. È rendere i passaggi abbastanza ripetibili da poter capire una build quando qualcosa va storto.
