project-cli

Persönliches CLI-Tool, das neue Projekte anlegt: Grundgerüst erzeugen, Git initialisieren, optional ein Remote-Repository auf GitHub oder Gitea anlegen und pushen. Läuft unter Windows und macOS.

Installation

npm i -g @robineb/project-cli

(Package auf npmjs.com, anonym installierbar – kein Account/Token nötig. Scoped, weil der naheliegende unscoped Name project-cli bereits an ein fremdes Paket vergeben ist. Der aufgerufene Befehl heißt trotzdem schlicht project-cli, das bestimmt der bin-Eintrag, nicht der Package-Name. Zusätzlich als @robin1053/project-cli auf GitHub Packages veröffentlicht, rein für die Sichtbarkeit im Repo; installieren lohnt sich darüber nur, wenn man ohnehin schon für GitHub Packages authentifiziert ist.)

Voraussetzungen

• Node.js 26+ (das Tool nutzt Node's native, Strip-only TypeScript-Ausführung – kein Build-Schritt nötig)
• Git
• Für den esp32-Stack zusätzlich PlatformIO Core (pio)

Benutzung

node index.ts [name] [--private]

Ohne Argumente führt node index.ts interaktiv durch:

1. Projektname
2. Stack (next, ts-lib, esp32, …)
3. Remote-Repository: keins / GitHub / Gitea
4. Grundgerüst wird erzeugt, Git initialisiert und der erste Commit gemacht
5. Bei Remote-Wahl: Repo wird angelegt und gepusht

-p, --private legt ein angelegtes Remote-Repo privat statt öffentlich an.

Bricht ab, wenn der Zielordner bereits existiert.

Stacks

| Stack | Beschreibung | |---|---| | next | Next.js (TypeScript, App Router) via create-next-app | | ts-lib | Eigenes TypeScript-Package-Template | | esp32 | PlatformIO/ESP32-Projekt (Arduino-Framework) |

Neue Stacks werden einfach als Eintrag in STACKS in index.ts ergänzt – entweder mit command (delegiert an einen externen Generator) oder mit template (kopiert einen Ordner aus templates/).

PlatformIO-Befehle (für esp32-Projekte)

Im Projektordner eines gescaffoldeten esp32-Projekts ausgeführt:

node <pfad-zu-project-cli>/index.ts build [env]
node <pfad-zu-project-cli>/index.ts upload [env]
node <pfad-zu-project-cli>/index.ts add-board

• build – Firmware bauen (pio run)
• upload – Firmware bauen und aufs Board flashen (pio run -t upload)
• add-board – neues ESP32-Board suchen (pio boards espressif32) und als [env:...]-Sektion zur platformio.ini hinzufügen

env ist optional – ohne Angabe wird interaktiv aus den in platformio.ini definierten [env:...]-Sektionen ausgewählt.

Remote-Repos & Zugangsdaten

GitHub- bzw. Gitea-Token werden in dieser Reihenfolge aufgelöst:

1. Umgebungsvariable (GITHUB_TOKEN bzw. GITEA_URL/GITEA_TOKEN)
2. gespeicherter Wert
3. interaktive Abfrage (wird danach für nächstes Mal gespeichert)

Tokens landen dabei im OS-eigenen Schlüsselbund über @napi-rs/keyring (Windows Credential Manager, macOS Keychain, Linux Secret Service/libsecret) – nicht in einer Klartextdatei. Die Gitea-URL (kein Geheimnis) bleibt plattformgerecht in conf (%APPDATA% unter Windows, ~/Library/Application Support unter macOS, XDG-Pfade unter Linux).

Token-Scopes: Gitea braucht write:repository. GitHub braucht „Administration" (Schreibrecht) auf einem Fine-grained PAT, oder repo/public_repo auf einem Classic PAT.

Entwicklung

Typecheck gegen die Root-tsconfig.json:

npx tsc --noEmit

Build für die globale Installation (kompiliert nach dist/ und kopiert templates/ dorthin, siehe bin in package.json):

npm run build
npm i -g .

Es gibt noch keine Tests.

Veröffentlichen

.github/workflows/publish.yaml läuft bei jedem GitHub Release (types: [published]) und veröffentlicht die gebaute Version zweimal parallel:

• als @robineb/project-cli auf npmjs.com via Trusted Publishing (OIDC) – kein Secret im Repo, npm tauscht den GitHub-Actions-OIDC-Token automatisch gegen einen kurzlebigen Publish-Token. (Klassische Access-Tokens mit direktem Publish-Recht werden von npm ab Januar 2027 abgeschafft – Trusted Publishing ist der empfohlene Ersatz.)
• als @robin1053/project-cli auf GitHub Packages (Auth über das eingebaute GITHUB_TOKEN, kein Secret nötig)

Trusted Publishing lässt sich laut npm erst einrichten, wenn das Paket mindestens einmal existiert – deshalb einmaliger manueller Bootstrap, danach läuft alles Weitere über die CI ohne jedes Secret:

npm run build
npm login
npm publish
npm trust github --allow-publish --file publish.yaml

Ablauf für jede weitere Version: version in package.json erhöhen, committen, Git-Tag + GitHub Release mit dieser Version anlegen – der Workflow übernimmt den Rest.

Lizenz

MIT