Für das, was es wert ist, denke ich, dass npx von "yarn create" inspiriert wurde, das ähnlich ist, aber nur für Pakete mit dem Präfix "create-" funktioniert. Nicht sicher, was die Pläne hier sind.

Ja, wir haben derzeit yarn create (versuchen Sie es zum Beispiel mit yarn create react-app ). Wir könnten es in Zukunft für andere Verben öffnen, aber das steht noch nicht auf der Roadmap.

Ich arbeite an npx-Bibliotheken. Es ist keine große Aufgabe, den vorhandenen npx-Code zu greifen und einfach die npm-bezogenen Eingeweide durch die Garn-äquivalenten Befehle zu ersetzen.

Ich werde das nicht direkt zu npx selbst hinzufügen, da es _agnostisch_ sein soll: npx führt keine Operationen aus, die mit Leuten kollidieren, die andere Paketmanager verwenden. Es ist nicht einmal erforderlich, dass npm auf dem System ist, also können Sie npm rm -g npm und npx wird gut funktionieren. Sie könnten also npx _is_ ypx sagen, es sei denn, Sie halten wirklich viel

(Zur Inspiration: npx ist in erster Linie von dieser langjährigen Funktionsanfrage inspiriert: https://github.com/npm/npm/issues/6053. Die meisten Funktionen konzentrieren sich darauf, _diesen_ Bedarf zu erfüllen. Die Auto-Installationsfunktion _wurde_ hinzugefügt post-yarn-create, und ist definitiv als verallgemeinerte Lösung für dieses spezielle Ding gedacht - aber es tut _weit mehr_ als das)

@sandys - Das von @zkat referenzierte Problem (npm/npm#6053) ist kein Problem für yarn da Sie einfach yarn x (oder yarn run x wenn Sie möchten) tun können explizit), wenn sich x in Ihrem ./node_modules/.bin Verzeichnis befindet. Ich glaube also nicht, dass eine Äquivalenz von npx dringend erforderlich ist.

Wenn Sie der Meinung sind, dass ein dringender Bedarf besteht, können Sie erklären, warum Sie ihn brauchen? Z.B. welches problem wird es für dich lösen?

Weiß jemand, ob yarn exec bundle exec ähnlich ist? Ich sehe es auf der CLI, aber nicht in den Dokumenten auf der Website. Ein schnelles Spielen mit yarn exec auf der Befehlszeile scheint installierte Binärdateien auszuführen, sodass Ihr Problem @sandys gelöst werden könnte.

FWIW, npm-run ist ein älteres Dienstprogramm, mit dem lokale node_modules Binärdateien ausgeführt werden können, und es hängt nicht von npm . Es hat jedoch keine Optionen, während npx voller Knöpfe ist.

@BYK Use Case läuft zB ypx greenkeeper-lockfile@1 oder ypx danger@2 auf CI, ohne diese als Deps zum Projekt selbst hinzuzufügen

@SimenB CI würde das Projekt normalerweise jedoch nicht wieder an die Versionskontrolle übergeben, daher spielt es keine Rolle, ob die Abhängigkeiten im Prozess

@MarkBennett Da yarn exec keine Skripte von package.json ausführt, glaube ich nicht, dass es der richtige Ort ist, um diese Funktion hinzuzufügen.

@BYK Ich bin nicht das OP, aber ich bin auf diese Funktionsanfrage gekommen, weil ich ein Paket auf meinem lokalen Computer hatte, aber nicht in meiner package.json. Daher würde meine App für mich laufen, aber nicht für jemanden, der eine saubere Installation meiner App durchgeführt hat. Dies ist ein Feature von Ruby Bundlers bundle exec , das mir gefällt - es wird nicht ausgeführt, es sei denn, alle Deps sind im Manifest.

Meine Hauptbeschwerde über yarn x ist, dass es versucht, ein Ziel von 3 (drei) verschiedenen Stellen aufzulösen: interne Garnbefehle, npm-Skripte und Bins.

Nehmen wir an, ich habe ein Tool mit Binärdatei namens check : 1) yarn check führt stattdessen seinen eigenen internen check Befehl aus 2) yarn run check führt die npm eines Verbrauchers aus Skript mit einem solchen Namen oder vielleicht mein Tool.

npx gibt eine starke Trennung der Konzepte: yarn x ist immer ein interner Befehl, yarn run x ist immer ein Skript und npx x ist immer eine Binärdatei, keine Notwendigkeit zu erraten und zu hoffen.

sowas wie kern

#!/usr/bin/env bash

package_name=$1
temp_dir="/tmp/ypx/$package_name/$(date +%s%N)"
mkdir -p $temp_dir
(cd $temp_dir; yarn add $package_name) && (PATH="$temp_dir/node_modules/.bin":$PATH; "$@")
rm -rf $temp_dir

@BYK ein anderer Anwendungsfall führt eine _binary_ eines Pakets aus, das noch nicht lokal installiert ist und ich möchte es einmal ausführen, ohne es danach selbst löschen zu müssen. npx ist eine Erweiterung des Verhaltens von yarn x weil Sie:

1. einen Befehl eines lokalen Pakets in ./node_modules/.bin/ im aktuellen Verzeichnis ausführen
2. Wenn das Paket nicht lokal vorhanden ist ODER das Verzeichnis ./node_modules/ nicht existiert, laden Sie das Paket in ein temporäres Verzeichnis mit seinen Abhängigkeiten herunter und rufen Sie den Befehl auf

dies geschieht transparent für den Benutzer.

ein hypothetisches ypx kann auch einen dritten Punkt anbieten, nämlich:

1. Wenn das Paket nicht lokal vorhanden ist UND es im Garn-Cache vorhanden ist UND es mit der neuesten Version übereinstimmt, rufen Sie den Befehl mit dem Cache auf, anstatt alle Pakete herunterzuladen

@BYK Es funktioniert nicht.
Installieren Sie babel-cli zum Beispiel: yarn add babel-cli
Führen Sie dann yarn babel-node --presets es2015 ./server.js wobei server.js eine Datei im aktuellen Verzeichnis ist und ein einfacher express API-Server ist.
Es funktioniert einfach nicht und sagt, dass die Datei nicht existiert. ( Error: Cannot find module )
Aber die Verwendung mit npx funktioniert npx babel-node --presets es2015 ./server.js

@BYK , soweit ich weiß, sucht npx nach Ihrem Befehl auf node_module/.bin/ auf dem lokalen Computer und wenn es keinen richtigen Befehl findet, wird es ein Paket aus dem Web holen, wenn es eines gibt, und Sie können immer auf dem neuesten Stand sein .
Garn erhält kein Paket aus dem Web, solange es nicht auf dem lokalen Computer installiert ist.

Können wir ein yarnx ?

@light24bulbs warum gerade?

Ehrlich gesagt denke ich, dass npx ein gutes Werkzeug ist, auch wenn es etwas zu "npm inc."-zentriert ist (wie viele der Werkzeuge von npm, um fair zu sein). Ein yarnx würde dieses Problem nicht lösen (es wäre notwendigerweise garnzentriert), daher bin ich mir nicht sicher, ob es eine gute Idee wäre.

Im Idealfall würde ich es vorziehen, dass npx den zu verwendenden Paketmanager automatisch erkennt oder zumindest die Konfiguration in einer rc-Datei ermöglicht. Ich würde vorschlagen, dieses Problem zu ihnen zu bringen und zu sehen, was sie sagen. Abhängig von ihrer Antwort können wir dann eine fundierte Diskussion führen 🙂

@arcanis npx selbst wird mit npm kombiniert, weil es mit npm gebündelt ist -- libnpx ist es nicht, und tatsächlich verwendet pnpx von pnpm das unter der Haube. Ich habe ein paar Patches hinzugefügt, um es für Zoltan zu ermöglichen. Ich werde keine Unterstützung für die automatische Erkennung hinzufügen, da dies einen Teil der Integration entfernt und die Dinge komplizierter und schwieriger zu unterstützen macht :)

Habe gerade dieses Problem gegoogelt und ich denke, es ist der richtige Ort, um nach Updates zu fragen. Gibt es ein vorhandenes Tool/eine Lösung oder planen Sie, dem Garn einige Funktionen hinzuzufügen?
Meine aktuellen Probleme mit npx sind zum Beispiel:

1. es lädt jedes Mal ein fehlendes Paket mit Abhängigkeiten herunter,
2. Es erstellt package-lock.json in Yarn-orientierten Projekten, was Warnungen verursacht und manuell entfernt werden muss.
   (insbesondere habe ich gerade npx gatsby new blog https://github.com/gatsbyjs/gatsby-starter-blog )

Beide Probleme scheinen perfekt zu passen, um sie für Garne zu lösen, wie

UPD: Der Hauptgrund für ypx ich erwähne, ist also nicht die binäre Ausführung (was bei Garn völlig in Ordnung ist), sondern die Möglichkeit, Pakete automatisch herunterzuladen, die ich ausführen möchte.

Ich stimme zu. Ich denke auch, dass es eine Möglichkeit gibt, die seltsame API von NPMs zu verbessern
ein bisschen. Ich denke, yarn exec COMMAND wäre sinnvoller als
yarnx . Ruby Bundler hatte einen sehr ähnlichen Befehl
https://bundler.io/man/bundle-exec.1.html

Am Mo, 17. Dez. 2018 um 14:29 Uhr Pavel Prokudin [email protected]
schrieb:

Habe gerade dieses Problem gegoogelt und ich denke, es ist der richtige Ort, um danach zu fragen
irgendwelche Aktualisierungen. Gibt es ein vorhandenes Tool/eine Lösung oder planen Sie, einige hinzuzufügen?
Funktionalität zum Garn?
Meine aktuellen Probleme mit npx sind zum Beispiel:

1. es lädt jedes Mal ein fehlendes Paket mit Abhängigkeiten herunter,
2. es erstellt package-lock.json in Yarn-orientierten Projekten, was dazu führt, dass
   Warnungen und müssen Sie es von Hand entfernen.
   (speziell führe ich gerade npx gatsby neuen Blog aus
   https://github.com/gatsbyjs/gatsby-starter-blog)

Beide Probleme scheinen perfekt zu passen, um sie für Garne wie @phra zu lösen
https://github.com/phra bereits als seinen dritten Punkt erwähnen.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/yarnpkg/yarn/issues/3937#issuecomment-447968558 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AAjhEng6juvpaK4xLx1KrVHccJAytnAfks5u5_CcgaJpZM4OY9aL
.

--
-Wald

yarn exec existiert bereits (mit einer anderen Bedeutung als der von Ihnen vorgeschlagenen) 🙂

Löst das neue yarn dlx dieses Problem?

cc @sandys @arcanis

https://yarnpkg.github.io/berry/cli/dlx

Ja! Um dieses Thema vorerst abzuschließen, habe ich noch nicht herausgefunden, ob wir das Feature auf die v1 zurückportieren wollen (wahrscheinlich nicht?).

Ich bin mir nicht sicher, ob es ein würdiger Ersatz ist. yarn dlx eslint --help braucht auf meinem Rechner 2,7 Sekunden, während npx eslint --help in 0,2 Sekunden fertig ist. Ruft man viele bin-Skripte auf, summiert sich das schnell zu inakzeptablen Werten.

Außerdem denke ich, dass stdout/stderr nicht von Garn geschrieben werden sollte, es sei denn, es liegt ein Fehler vor, damit die Ausgabe des Skripts analysiert werden kann.

@silverwind der Timing-Unterschied scheint ziemlich stark zu sein. Ist dies in mehreren Durchläufen konsistent reproduzierbar? Wenn ja, würde ich ein neues Problem zur Untersuchung einreichen, da wir sicherlich nicht wollen, dass es langsam wird.

In Bezug auf stdout/stderr von Yarn _glaube_ ich, dass Sie yarn --silend dlx eslint , um alle nicht kritischen Yarn-Ausgaben zu unterdrücken. @arcanis kannst du das letzte bestätigen?

@light24bulbs warum gerade?

Für alle Leute, die ein Paket im Web finden, beachten Sie, dass die Installationsanweisungen npx something something , aber in der Garnwelt bleiben möchten.

Löst das neue yarn dlx dieses Problem?

Ist yarn dlx ein exakter s/npx/yarn dlx/ Drop-in-Ersatz für npx ? Wenn nicht, löst es dieses Problem nicht.

Versuche dies
https://www.npmjs.com/package/ynpx

Garn erstellen & npx & npm init

Demo

https://www.npmjs.com/package/create-react-app

$ yarn create react-app

$ npx create-react-app

$ npm init react-app

https://www.npmtrends.com/npm-vs-npx-vs-yarn

@light24bulbs - um wiederholen , bin ich hierher gekommen, weil die Schnellstartanleitung von Storybook sagt, dass man npx , um es zu installieren , und ich kein einfaches Rezept hatte, wie man den entsprechenden Zauberspruch mit yarn beschwört

Ich bin auch auf dem gleichen Boot wie @codekiln. Immer wenn ich einige Anweisungen befolge, die sagen, dass npx ... , habe ich keine Ahnung, was das Äquivalent von yarn ist. Ein Beispiel ist npx tslint-to-eslint-config .

@light24bulbs - um wiederholen , bin ich hierher gekommen, weil die Schnellstartanleitung von Storybook sagt, dass man npx , um es zu installieren , und ich kein einfaches Rezept hatte, wie man den entsprechenden Zauberspruch mit yarn beschwört

Genauso wie hier, mit der Installationsanleitung von Kondensatorjs https://capacitorjs.com/docs/getting-started , ist das Gefühl, dass dies den Benutzer davon überzeugt, das Garn aufzugeben und zu npm zurückzukehren

https://yarnpkg.com/en/docs/cli/exec

https://yarnpkg.com/en/docs/cli/exec

404 Seite nicht gefunden

Ich denke, @delanym meinte diese Seite (aber ich glaube nicht, dass dies npx repliziert): https://yarnpkg.com/cli/exec