Por lo que vale, creo que npx se inspiró en "yarn create", que es similar pero solo funciona para paquetes con el prefijo "create-". No estoy seguro de cuáles son los planes aquí.

Sí, actualmente tenemos yarn create (intente usar yarn create react-app , por ejemplo). Podríamos abrirlo a otros verbos en el futuro, pero eso aún no está en la hoja de ruta.

Estoy trabajando en npx de biblioteca. No es una gran tarea tomar el código npx existente y simplemente reemplazar las agallas relacionadas con npm con los comandos equivalentes a yarn.

No agregaré eso directamente a npx en sí, ya que está _ destinado a ser agnóstico: npx no realiza operaciones que entren en conflicto con las personas que usan otros administradores de paquetes. Ni siquiera requiere que npm esté en el sistema, por lo que puede npm rm -g npm y npx funcionará bien. Por lo tanto, podría decir npx _is_ ypx , a menos que esté muy convencido de compartir caché, que es algo bonito.

(en re-inspiración: npx se inspira principalmente en esta solicitud de función de larga data: https://github.com/npm/npm/issues/6053. La mayor parte de su funcionalidad se centra en satisfacer _esta_ necesidad. La función de instalación automática _fue_ agregada post-yarn-create, y definitivamente pretende ser una solución generalizada real para esa cosa en particular, pero hace _mucho más_ que eso)

@sandys : el problema al que se hace referencia yarn ya que puedes hacer yarn x (o yarn run x si quieres ser explícito) si x está en su directorio ./node_modules/.bin . Así que no creo que exista una necesidad urgente de npx de

Si cree que existe una gran necesidad, ¿puede explicar por qué la necesita? P.ej. ¿Qué problema te solucionará?

¿Alguien sabe si yarn exec es similar a bundle exec ? Lo veo en la CLI pero no en los documentos del sitio web. Un juego rápido con yarn exec en la línea de comandos parece que ejecuta binarios instalados, por lo que podría resolver su problema @sandys.

FWIW, npm-run es una utilidad más antigua que permite ejecutar binarios locales node_modules , y no depende de npm . Sin embargo, no tiene opciones, mientras que npx está lleno de perillas.

El caso de uso de @BYK se está ejecutando, por ejemplo, ypx greenkeeper-lockfile@1 o ypx danger@2 en CI sin agregarlos como departamentos al proyecto en sí

Sin embargo, @SimenB CI generalmente no devolvería el proyecto al control de versiones, por lo que no importa si agrega las dependencias en el proceso, ¿verdad?

@MarkBennett Dado que yarn exec no ejecuta scripts desde package.json , no creo que sea el lugar adecuado para agregar esta función.

@BYK No soy el OP, pero llegué a esta solicitud de función porque tenía un paquete en mi máquina local pero no en mi package.json. Por lo tanto, mi aplicación se ejecutará para mí, pero no para cualquiera que haya realizado una instalación limpia de mi aplicación. Esta es una característica del bundle exec del paquete de ruby ​​que me gusta; no se ejecutará a menos que todos los deps estén en el manifiesto.

Mi principal queja sobre yarn x es que está tratando de resolver un objetivo desde 3 (tres) lugares diferentes: comandos internos de yarn, scripts npm y bins.

Digamos que tengo una herramienta con binario llamado check : 1) yarn check ejecutará su propio comando interno check lugar 2) yarn run check ejecutará un npm del consumidor script con ese nombre o tal vez mi herramienta.

npx da una fuerte separación de conceptos: yarn x es siempre un comando interno, yarn run x es siempre un script y npx x es siempre un binario, no es necesario adivinar y esperar.

algo como lo esencial

#!/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 otro caso de uso es ejecutar un _binary_ de un paquete que aún no está instalado localmente y quiero ejecutarlo una vez, sin molestarme en eliminarlo por mi cuenta después. npx es una extensión del comportamiento de yarn x porque puede:

1. ejecutar un comando de un paquete local en ./node_modules/.bin/ en el directorio actual
2. si el paquete no está presente localmente O el directorio ./node_modules/ no existe, descargue el paquete en un directorio temporal con sus dependencias e invoque el comando

esto se hace de forma transparente para el usuario.

un hipotético ypx también puede ofrecer un tercer punto que es:

1. si el paquete no está presente localmente Y está presente en el caché de hilo Y coincide con la última versión, invoque el comando usando el caché en lugar de descargar todos los paquetes

@BYK No funciona.
Instale babel-cli por ejemplo: yarn add babel-cli
Luego ejecute yarn babel-node --presets es2015 ./server.js que server.js es un archivo en el directorio actual y es un simple servidor express api.
Simplemente no funciona y dice que el archivo no existe. ( Error: Cannot find module )
Pero usarlo con npx funciona npx babel-node --presets es2015 ./server.js

@BYK , hasta donde yo sé, npx buscará su comando en node_module/.bin/ en la máquina local y si no encontró el comando adecuado, obtendrá el paquete de la web si hay alguno y usted puede estar siempre actualizado .
el hilo no recibe el paquete de la web mientras no esté instalado en la máquina local.

¿Podemos obtener un yarnx ?

@ light24bulbs ¿por qué en particular?

Francamente, creo que npx es una buena herramienta aunque un poco demasiado "npm inc." - centrada (como muchas de las herramientas de npm, para ser justos). Un yarnx no resolvería este problema (necesariamente estaría centrado en el hilo), por lo que no estoy muy seguro de que sea una buena idea.

Idealmente, preferiría npx para detectar automáticamente el administrador de paquetes a usar, o al menos para permitir configurarlo dentro de un archivo rc. Sugeriría traerles este tema y ver qué dicen. Dependiendo de su respuesta, podremos tener una discusión informada 🙂

@arcanis npx en sí se combina con npm porque está incluido con npm - libnpx no lo es, y de hecho, eso es lo que pnpx de pnpm usa bajo el capó. Agregué un par de parches para hacerlo posible para Zoltan. No agregaré soporte de detección automática porque elimina parte de la integración y hace que las cosas sean más complicadas y difíciles de soportar :)

Acabo de buscar en Google este problema y creo que es el lugar apropiado para preguntar acerca de las actualizaciones. ¿Existe alguna herramienta / solución, o planea agregar alguna funcionalidad al hilo?
Por ejemplo, mis problemas actuales con npx son:

1. descarga el paquete ausente con dependencias cada vez,
2. crea package-lock.json en proyectos orientados a Yarn, lo que genera advertencias y es necesario eliminarlo con las manos.
   (específicamente, acabo de ejecutar npx gatsby new blog https://github.com/gatsbyjs/gatsby-starter-blog )

Ambos problemas parecen una combinación perfecta para resolver un hilo como el que @phra ya mencionó como su tercer punto.

UPD: Básicamente, la razón principal de ypx que menciono no es la ejecución binaria (que está totalmente bien con el hilo), sino la capacidad de descargar automáticamente los paquetes que pretendo ejecutar.

Estoy de acuerdo. También creo que existe la oportunidad de mejorar la extraña API de NPM
un poquito. Creo que llamar a yarn exec COMMAND tendría más sentido que
yarnx . El paquete de Ruby tenía un comando muy similar
https://bundler.io/man/bundle-exec.1.html

El lunes, 17 de diciembre de 2018 a las 2:29 p.m. Pavel Prokudin [email protected]
escribió:

Acabo de buscar en Google este problema y creo que es un lugar apropiado para preguntar
alguna actualización. ¿Existe alguna herramienta / solución existente, o planea agregar alguna
funcionalidad al hilo?
Por ejemplo, mis problemas actuales con npx son:

1. descarga el paquete ausente con dependencias cada vez,
2. crea package-lock.json en proyectos orientados a Yarn, lo que provoca
   advertencias y es necesario quitarlo con las manos.
   (específicamente solo ejecuto npx gatsby new blog
   https://github.com/gatsbyjs/gatsby-starter-blog)

Ambos problemas parecen una combinación perfecta para resolver para hilos como @phra
https://github.com/phra ya menciono como su tercer punto.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/yarnpkg/yarn/issues/3937#issuecomment-447968558 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAjhEng6juvpaK4xLx1KrVHccJAytnAfks5u5_CcgaJpZM4OY9aL
.

-
-Para descanso

yarn exec ya existe (con un significado diferente al que sugieres) 🙂

¿El nuevo yarn dlx resuelve este problema?

cc @sandys @arcanis

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

¡Sí! Cerrando este problema por ahora, aún no he descubierto si queremos volver a exportar la función a la v1 (¿probablemente no?).

No estoy seguro de que sea un reemplazo digno. yarn dlx eslint --help tarda 2.7 segundos en mi máquina mientras que npx eslint --help termina en 0.2s. Si uno llama a muchos scripts bin, esto rápidamente se sumará a valores inaceptables.

Además, creo que stdout / stderr no debería escribirse con yarn a menos que haya un error, para permitir analizar la salida del script.

@silverwind, la diferencia de tiempo parece bastante marcada. ¿Es esto reproducible en múltiples ejecuciones de manera consistente? En caso afirmativo, presentaría un nuevo problema para su investigación, ya que seguramente no queremos que sea lento.

Con respecto a stdout / stderr de Yarn, creo que puede usar yarn --silend dlx eslint para suprimir toda la salida de Yarn no crítica. @arcanis ¿puedes confirmar este último?

@ light24bulbs ¿por qué en particular?

Para todas las personas que encuentren algún paquete en la web, vea que las instrucciones de instalación involucran npx something something , pero quieren permanecer en el mundo de los hilos.

¿El nuevo yarn dlx resuelve este problema?

¿Es yarn dlx un s/npx/yarn dlx/ reemplazo directo exacto de npx ? De lo contrario, no resuelve este problema.

prueba esto
https://www.npmjs.com/package/ynpx

yarn create & npx & npm init

manifestación

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 - para hacerme eco de la guía de inicio rápido de Storybook dice que use npx para instalarlo , y no tenía una receta fácil sobre cómo encantar el hechizo equivalente con yarn . Si hay un conjunto equivalente de comandos para yarn, deberíamos publicarlos en el sitio web de yarn, de modo que esa página (en lugar de este hilo) esté en la parte superior de los resultados de búsqueda de Google para "versión yarn de npx".

También estoy en el mismo barco que @codekiln. Siempre que sigo algunas instrucciones que dicen ejecutar npx ... , no tengo idea de cuál es el yarn . Un ejemplo es npx tslint-to-eslint-config .

@ light24bulbs - para hacerme eco de la guía de inicio rápido de Storybook dice que use npx para instalarlo , y no tenía una receta fácil sobre cómo encantar el hechizo equivalente con yarn . Si hay un conjunto equivalente de comandos para yarn, deberíamos publicarlos en el sitio web de yarn, de modo que esa página (en lugar de este hilo) esté en la parte superior de los resultados de búsqueda de Google para "versión yarn de npx".

Lo mismo aquí, con la guía de instalación de capacitorjs https://capacitorjs.com/docs/getting-started , la sensación es que esto persuade al usuario a abandonar el hilo y volver a npm

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

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

404 Pagina no encontrada

Supongo que @delanym se refería a esta página (pero no creo que esto se repita npx ): https://yarnpkg.com/cli/exec