default error output formatting isn't ergonomic

Offen
  • Stimmt etwas nicht?
#114 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
25/100
Issue-Typ
Feature
Klarheit
Muss geklärt werden
Aktivitätsstatus
Veraltet
Tech-Stack
javascript, shell
Bereich
cli, release

Rechercherichtung

Beginne damit, die Formatierung der standardmäßigen Fehlerausgabe und die Behandlung von failCmd in semantic-release/exec zu finden, und reproduziere dann einen fehlgeschlagenen Befehl, dessen stdout mehrzeiligen Text und ANSI-Escape-Sequenzen enthält. Erledigt ist es, wenn die Standardausgabe lesbar ist und das Quoting-Problem des Issues behoben ist, ohne ein benutzerdefiniertes failCmd zu erfordern.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

I know I can provide a failCmd, and I'll do that, but it seems to me the default failure output could be improved. It prints the stdout stringified, which is an assault on the eyes...

Aside from that it's not 100% straightforward how to deal with quoting in making a failCmd that will print the output as-is.

  shortMessage: 'Command failed with exit code 1: ./run release 7.0.0',
  command: './run release 7.0.0',
  exitCode: 1,
  signal: undefined,
  signalDescription: undefined,
  stdout:
   'Login Succeeded\nmaster\njcore/clarity\n*********************************************\nSuccessfully compiled 414 files with Babel.\nSuccessfully compiled 714 files with Babel.\nHappy[1]: Version: 5.0.1. Threads: 4\nHappy[1]: All set; signaling webpack to proceed.\nHash: \u001b[1m8a4bddc52b72ec4bb568\u001b[39m\u001b[22m\nVersion: webpack \u001b[1m4.28.0\u001b[39m\u001b[22m\nTime: \u001b[1m64663\u001b[39m\u001b[22mms\nBuilt at: 09/30/2020 \u001b[1m10:20:58 PM\u001b[39m\u001b[22m\n                               \u001b[1mAsset\u001b[39m\u001b[22m       \u001b[1mSize\u001b[39m\u001b[22m  \u001b[1mChunks\u001b[39m\u001b[22m  \u001b[1m\u001b[39m\u001b[22m           \u001b[1m\u001b[39m\u001b[22m       \u001b[1mChunk Names\u001b[39m\u001b[22m\n           \u001b[1m\u001b[32m0_e0568fa039ca1be3a035.js\u001b[39m\u001b[22m   46.9 KiB       \u001b[1m0\u001b[39m\u001b[22m  \u001b[1m\u001b[32m[emitted]\u001b[39m\u001b[22m         \n       \u001b[1m\u001b[32m0_e0568fa039ca1be3a035.js.map\u001b[39m\u001b[22m    123 KiB       \u001b[1m0\u001b[39m\u001b[22m  \u001b[1m\u001b[32m[emitted]\u001b[39m\u001b[22m         \n          \u001b[1m\u001b[32m11_5b4b19d4d23cb7309e43.js\u001b[39m\u001b[22m   71.6 KiB      \u001b[1m11\u001b[39m\u001b[22m  \u001b[1m\u001b[32m[emitted]\u001b[39m\u001b[22m         \n      \u001b[1m\u001b[32m11_5b4b19d4d23cb7309e43.js.map\u001b[39m\u001b[22m    300 KiB      \u001b[1m11\u001b[39m\u001b[22m  \u001b[1m\u001b[32m[emitted]\u001b[39m\u001b[22m         \n          \u001b[1m\u001b[32m12_1530a720f145ffeffdf4.js\u001b[39m\u001b[22m   26.1 KiB      \u001b[1m12\u001b[39m\u001b[22m  \u001b[1m\u001b[32m[emitted]\u001b[39m\u001b[22m         \n      \u001b[1m\u001b[32m12_1530a720f145ffeffdf4.js.map\u001b[39m\u001b[22m   56.2 KiB      \u001b[1m12\u001b[39m\u001b[22m  \u001
Vorherrschende Sprache
JavaScript
Sterne
166
Forks
27
Keine gemergten PRs in 30 T.

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus semantic-release/exec

Alle Issues in semantic-release/exec

Ähnliche Issues

Weitere Issues zu JavaScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.