Pour ce que ça vaut, je pense que npx a été inspiré par "yarn create" qui est similaire mais ne fonctionne que pour les packages préfixés par "create-". Je ne sais pas quels sont les plans ici.

Oui, nous avons actuellement yarn create (essayez d'utiliser yarn create react-app , par exemple). Nous pourrions l'ouvrir à d'autres verbes dans le futur, mais ce n'est pas encore sur la feuille de route.

Je travaille sur la bibliothèque npx. Ce n'est pas une tâche énorme de récupérer le code npx existant et de simplement remplacer les tripes liées à npm par les commandes équivalentes au fil.

Je n'ajouterai pas cela directement à npx lui-même, car il est censé être agnostique : npx n'effectue aucune opération qui entre en conflit avec les personnes utilisant d'autres gestionnaires de packages. Il n'est même pas nécessaire que npm soit sur le système, vous pouvez donc npm rm -g npm et npx fonctionnera très bien. Vous pourriez donc dire npx _is_ ypx , à moins que vous ne soyez vraiment convaincu par le partage de cache, ce qui est une jolie chose.

(en ré-inspiration : npx est principalement inspiré par cette demande de fonctionnalité de longue date : https://github.com/npm/npm/issues/6053. La plupart de ses fonctionnalités sont centrées sur la satisfaction de _ce_ besoin. La fonctionnalité d'installation automatique _a_ été ajoutée post-yarn-create, et est certainement destiné à être une solution généralisée réelle à cette chose particulière - mais il fait _beaucoup plus_ que cela)

@sandys - Le problème référencé @zkat (npm/npm#6053) n'est pas un problème sur yarn puisque vous pouvez simplement faire yarn x (ou yarn run x si vous voulez être explicite) si x est dans votre répertoire ./node_modules/.bin . Je ne pense donc pas qu'il y ait un besoin urgent d'équivalence npx .

Si vous pensez qu'il existe un besoin important, pouvez-vous expliquer pourquoi vous en avez besoin ? Par exemple. quel problème cela résoudra-t-il pour vous ?

Est-ce que quelqu'un sait si yarn exec est similaire à bundle exec ? Je le vois sur le CLI mais pas dans les docs sur le site Web. Un jeu rapide avec yarn exec sur la ligne de commande semble exécuter les binaires installés, ce qui pourrait résoudre votre problème @sandys.

FWIW, npm-run est un utilitaire plus ancien qui permet d'exécuter des binaires locaux node_modules , et cela ne dépend pas de npm . Il n'a cependant aucune option, alors que npx est plein de boutons.

Le cas d'utilisation @BYK est en cours d'exécution, par exemple ypx greenkeeper-lockfile@1 ou ypx danger@2 sur CI sans les ajouter en tant que deps au projet lui-même

@SimenB CI ne remettra généralement pas le projet au contrôle de version, donc cela n'a pas d'importance s'il ajoute les dépendances dans le processus, n'est-ce pas ?

@MarkBennett Puisque yarn exec n'exécute pas les scripts de package.json je ne pense pas que ce soit le bon endroit pour ajouter cette fonctionnalité.

@BYK Je ne suis pas l'OP, mais je suis venu à cette demande de fonctionnalité car j'avais un package sur ma machine locale mais pas dans mon package.json. Par conséquent, mon application fonctionnerait pour moi, mais pas pour toute personne ayant effectué une installation propre de mon application. C'est une fonctionnalité de bundle exec de ruby ​​bundler que j'aime - elle ne fonctionnera que si tous les deps sont dans le manifeste.

Mon principal reproche à propos de yarn x est qu'il essaie de résoudre une cible à partir de 3 (trois) endroits différents: commandes internes de fil, scripts npm et bacs.

Disons que j'ai un outil avec un binaire nommé check : 1) yarn check exécutera sa propre commande interne check place 2) yarn run check exécutera le npm d'un consommateur script avec un tel nom ou peut-être mon outil.

npx donne une forte séparation des concepts : yarn x est toujours une commande interne, yarn run x est toujours un script et npx x est toujours un binaire, pas besoin deviner et espérer.

quelque chose comme l' essentiel

#!/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 un autre cas d'utilisation exécute un _binaire_ d'un package qui n'est pas encore installé localement et je souhaite l'exécuter une fois, sans prendre la peine de le supprimer moi-même après. npx est une extension du comportement de yarn x car vous pouvez :

1. exécuter une commande d'un package local dans le ./node_modules/.bin/ dans le répertoire courant
2. si le package n'est pas présent localement OU le répertoire ./node_modules/ n'existe pas, téléchargez le package dans un répertoire temporaire avec ses dépendances et invoquez la commande

cela se fait de manière transparente pour l'utilisateur.

un ypx hypothétique peut aussi offrir un troisième point qui est :

1. si le package n'est pas présent localement ET qu'il est présent dans le cache de fil ET qu'il correspond à la dernière version, invoquez la commande en utilisant le cache au lieu de télécharger tous les packages

@BYK Cela ne fonctionne pas.
Installez babel-cli par exemple : yarn add babel-cli
Ensuite, exécutez yarn babel-node --presets es2015 ./server.js qui server.js est un fichier dans le répertoire courant et est un simple serveur api express .
Cela ne fonctionne tout simplement pas et dit que le fichier n'existe pas. ( Error: Cannot find module )
Mais l'utiliser avec npx fonctionne npx babel-node --presets es2015 ./server.js

@BYK pour autant que je sache, npx recherchera votre commande sur node_module/.bin/ sur la machine locale et s'il ne trouve pas la commande appropriée, il obtiendra le package du Web s'il y en a et vous pouvez être toujours à jour .
fil n'obtient pas de package à partir du Web tant qu'il n'est pas installé sur la machine locale.

Pouvons-nous obtenir un yarnx ?

@light24bulbs pourquoi en particulier ?

Franchement, je pense que npx est un bon outil même s'il est un peu trop centré sur "npm inc." (comme beaucoup d'outils de npm, pour être juste). Un yarnx ne résoudrait pas ce problème (ce serait nécessairement centré sur le fil), donc je ne suis pas trop sûr que ce serait une bonne idée.

Idéalement, je préférerais que npx détecte automatiquement le gestionnaire de paquets à utiliser, ou au moins permette de le configurer dans un fichier rc. Je suggère de leur apporter cette question et de voir ce qu'ils disent. En fonction de leur réponse nous pourrons alors avoir une discussion éclairée 🙂

@arcanis npx lui-même est combiné avec npm car il est fourni avec npm -- libnpx ne l'est pas, et en fait, c'est ce que pnpx de pnpm utilise sous le capot. J'ai ajouté quelques correctifs pour rendre cela possible pour Zoltan. Je n'ajouterai pas la prise en charge de la détection automatique car cela supprime une partie de l'intégration et rend les choses plus compliquées et plus difficiles à prendre en charge :)

Je viens de rechercher ce problème sur Google et je pense que c'est l'endroit approprié pour demander des mises à jour. Existe-t-il un outil/une solution ou envisagez-vous d'ajouter des fonctionnalités au fil ?
Par exemple, mes problèmes actuels avec npx sont :

1. il télécharge le package absent avec des dépendances à chaque fois,
2. il crée package-lock.json dans les projets orientés Yarn, ce qui provoque des avertissements et doit être supprimé à la main.
   (plus précisément, je viens d'exécuter npx gatsby new blog https://github.com/gatsbyjs/gatsby-starter-blog )

Ces deux problèmes semblent être une correspondance parfaite à résoudre pour le fil comme @phra déjà mentionné comme son troisième point.

UPD: Donc, la principale raison pour laquelle je mentionne ypx n'est pas l'exécution binaire (ce qui est tout à fait correct avec le fil), mais la possibilité de télécharger automatiquement les packages que j'ai l'intention d'exécuter.

Je suis d'accord. Je pense aussi qu'il y a une opportunité d'améliorer l'API étrange des NPM
un peu. Je pense qu'appeler yarn exec COMMAND aurait plus de sens que
yarnx . Ruby bundler avait une commande très similaire
https://bundler.io/man/bundle-exec.1.html

Le lundi 17 décembre 2018 à 14h29 Pavel Prokudin [email protected]
a écrit:

Je viens de rechercher ce problème sur Google et je pense qu'il est approprié de poser des questions sur
les mises à jour. Existe-t-il un outil/une solution existante, ou envisagez-vous d'en ajouter
fonctionnalité au fil?
Par exemple, mes problèmes actuels avec npx sont :

1. il télécharge le package absent avec des dépendances à chaque fois,
2. il crée package-lock.json dans les projets orientés fil qui provoque
   avertissements et devez l'enlever à la main.
   (plus précisément, je viens d'exécuter le nouveau blog npx gatsby
   https://github.com/gatsbyjs/gatsby-starter-blog)

Ces deux problèmes semblent correspondre parfaitement à la résolution d'un fil comme @phra
https://github.com/phra mentionne déjà comme son troisième point.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/yarnpkg/yarn/issues/3937#issuecomment-447968558 , ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/AAjhEng6juvpaK4xLx1KrVHccJAytnAfks5u5_CcgaJpZM4OY9aL
.

--
-Forêt

yarn exec existe déjà (avec un sens différent de ce que vous suggérez) 🙂

Le nouveau yarn dlx résout-il ce problème ?

cc @sandys @arcanis

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

Ouais! En fermant ce problème pour l'instant, je n'ai pas encore déterminé si nous voudrons rétroporter la fonctionnalité vers la v1 (probablement pas ?).

Je ne suis pas sûr que ce soit un remplacement digne. yarn dlx eslint --help prend 2,7 secondes sur ma machine tandis que npx eslint --help termine en 0,2s. Si l'on appelle beaucoup de scripts bin, cela s'ajoutera rapidement à des valeurs inacceptables.

De plus, je pense que stdout/stderr ne doit pas être écrit par thread à moins qu'il n'y ait une erreur, pour permettre l'analyse de la sortie du script.

@silverwind la différence de synchronisation semble assez frappante. Est-ce reproductible en plusieurs passages de manière cohérente ? Si oui, je déposerais un nouveau problème pour enquête car nous ne voulons certainement pas que cela soit lent.

En ce qui concerne stdout/stderr de Yarn, je pense que vous pouvez utiliser yarn --silend dlx eslint pour supprimer toutes les sorties Yarn non critiques. @arcanis peux-tu confirmer ce dernier ?

@light24bulbs pourquoi en particulier ?

Pour toutes les personnes qui trouvent un paquet sur le Web, voyez que les instructions d'installation impliquent npx something something , mais veulent rester dans le monde du fil.

Le nouveau yarn dlx résout-il ce problème ?

Est-ce que yarn dlx un remplacement exact de s/npx/yarn dlx/ pour npx ? Si ce n'est pas le cas, cela ne résout pas ce problème.

essaye ça
https://www.npmjs.com/package/ynpx

fil créer & npx & npm init

démo

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 - pour faire écho à @rulatir , je suis arrivé ici parce que le guide de démarrage rapide de Storybook dit d'utiliser npx pour l'installer , et je n'avais pas de recette simple pour savoir comment incanter le sort équivalent avec yarn . S'il existe un ensemble équivalent de commandes pour le fil, nous devons les publier sur le site Web de fil, de sorte que cette page (au lieu de ce fil) soit en haut des résultats de recherche Google pour "version fil de npx".

Je suis aussi sur le même bateau que @codekiln. Chaque fois que je suis des instructions qui disent run npx ... , je n'ai aucune idée de ce qui est l'équivalent yarn . Un exemple est npx tslint-to-eslint-config .

@light24bulbs - pour faire écho à @rulatir , je suis arrivé ici parce que le guide de démarrage rapide de Storybook dit d'utiliser npx pour l'installer , et je n'avais pas de recette simple pour savoir comment incanter le sort équivalent avec yarn . S'il existe un ensemble équivalent de commandes pour le fil, nous devons les publier sur le site Web de fil, de sorte que cette page (au lieu de ce fil) soit en haut des résultats de recherche Google pour "version fil de npx".

Idem ici, avec le guide d'installation de condensateurjs https://capacitorjs.com/docs/getting-started , le sentiment est que cela persuade l'utilisateur d'abandonner le fil et de revenir à npm

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

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

404 Page non trouvée

Je suppose que @delanym voulait dire cette page (mais je ne pense pas que cela reproduise npx ): https://yarnpkg.com/cli/exec