Pelo que vale a pena, acho que npx foi inspirado por "yarn create" que é semelhante, mas só funciona para pacotes com o prefixo "create-". Não tenho certeza de quais são os planos aqui.

Sim, atualmente temos yarn create (tente usar yarn create react-app , por exemplo). Podemos abri-lo para outros verbos no futuro, mas isso ainda não está no roteiro.

Estou trabalhando no npx de biblioteca. Não é uma tarefa enorme pegar o código npx existente e apenas substituir os guts relacionados ao npm pelos comandos equivalentes ao yarn.

Não vou adicionar isso diretamente ao próprio npx, uma vez que _ significa_ ser agnóstico: o npx não executa nenhuma operação que entre em conflito com pessoas que usam outros gerenciadores de pacotes. Ele nem mesmo exige que o npm esteja no sistema, então você pode npm rm -g npm e o npx funcionará perfeitamente. Então você poderia dizer npx _is_ ypx , a menos que você se sinta realmente forte sobre o compartilhamento de cache, o que é uma coisa bonita.

(em inspiração: npx é inspirado principalmente por esta solicitação de recurso de longa data: https://github.com/npm/npm/issues/6053. A maioria de sua funcionalidade gira em torno de cumprir _esta_ necessidade. O recurso de instalação automática _foi_ adicionado post-yarn-create, e definitivamente pretende ser uma solução generalizada real para aquela coisa em particular - mas faz _muito mais_ do que isso)

@sandys - O problema @zkat referenciado (npm / npm # 6053) não é um problema em yarn pois você pode apenas fazer yarn x (ou yarn run x se quiser explícito) se x estiver em seu diretório ./node_modules/.bin . Portanto, não acho que haja uma necessidade urgente de equivalência de npx .

Se você acha que há uma necessidade forte, pode explicar por que você precisa dela? Por exemplo. que problema isso vai resolver para você?

Alguém sabe se yarn exec é semelhante a bundle exec ? Vejo isso na CLI, mas não nos documentos do site. Uma rápida jogada com yarn exec na linha de comando parece que executa binários instalados, então pode resolver seu problema @sandys.

FWIW, npm-run é um utilitário mais antigo que permite a execução de binários node_modules e não depende de npm . Porém, ele não tem nenhuma opção, enquanto npx está cheio de botões.

@BYK O caso de uso está sendo executado, por exemplo, ypx greenkeeper-lockfile@1 ou ypx danger@2 no CI sem adicioná-los como departamentos ao próprio projeto

O @SimenB CI normalmente não comprometeria o projeto de volta ao controle de versão, então não importa se adiciona as dependências no processo, certo?

@MarkBennett Visto que yarn exec não executa scripts de package.json , não acho que seja o lugar certo para adicionar esse recurso.

@BYK Não sou o OP, mas cheguei a esta solicitação de recurso porque tinha um pacote em minha máquina local, mas não em meu package.json. Portanto, meu aplicativo seria executado para mim, mas não para qualquer pessoa que fizesse uma instalação limpa do meu aplicativo. Este é um recurso de bundle exec do bundler de ruby ​​que eu gosto - ele não será executado a menos que todos os departamentos estejam no manifesto.

Minha principal reclamação sobre yarn x é que ele está tentando resolver um alvo de 3 (três) lugares diferentes: comandos internos do yarn, scripts npm e bins.

Digamos que eu tenha uma ferramenta com binário denominado check : 1) yarn check executará seu próprio comando check interno em vez de 2) yarn run check executará o npm de um consumidor script com esse nome ou talvez minha ferramenta.

npx fornece uma forte separação de conceitos: yarn x é sempre um comando interno, yarn run x é sempre um script e npx x é sempre um binário, sem necessidade adivinhar e esperar.

algo como essência

#!/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 outro caso de uso está executando um _binário_ de um pacote que ainda não está instalado localmente e quero executá-lo uma vez, sem me preocupar em excluí-lo sozinho depois. npx é uma extensão do comportamento de yarn x porque você pode:

1. execute um comando de um pacote local em ./node_modules/.bin/ no diretório atual
2. se o pacote não estiver presente localmente OU o diretório ./node_modules/ não existir, baixe o pacote em um diretório temporário com suas dependências e invoque o comando

isso é feito de forma transparente para o usuário.

um hipotético ypx também pode oferecer um terceiro ponto que é:

1. se o pacote não estiver presente localmente E estiver presente no cache do yarn E corresponder à versão mais recente, invoque o comando usando o cache em vez de baixar todos os pacotes

@BYK Não funciona.
Instale babel-cli por exemplo: yarn add babel-cli
Em seguida, execute yarn babel-node --presets es2015 ./server.js que server.js é um arquivo no diretório atual e é um servidor de api express simples.
Ele simplesmente não funciona e diz que o arquivo não existe. ( Error: Cannot find module )
Mas usá-lo com npx funciona npx babel-node --presets es2015 ./server.js

@BYK , tanto quanto eu sei, npx irá procurar pelo seu comando em node_module/.bin/ na máquina local e se não encontrar o comando adequado irá obter o pacote da web se houver algum e você pode estar sempre atualizado .
yarn não obtém pacote da web enquanto não estiver instalado na máquina local.

Podemos obter um yarnx ?

@ light24bulbs por que em particular?

Francamente, acho que npx é uma boa ferramenta, mesmo que um pouco "npm inc." - centrada (como muitas das ferramentas de npm, para ser justo). A yarnx não resolveria este problema (seria necessariamente centrado no fio), então não tenho certeza se seria uma boa ideia.

Idealmente, eu preferiria que npx detectasse automaticamente o gerenciador de pacotes a ser usado, ou pelo menos permitir sua configuração dentro de um arquivo rc. Eu sugiro trazer esse problema para eles e ver o que eles dizem. Dependendo da resposta deles, poderemos ter uma discussão informada 🙂

O próprio libnpx não é, e de fato, é isso que pnpx do pnpm usa nos bastidores. Eu adicionei alguns patches para tornar possível para o Zoltan. Não vou adicionar suporte à detecção automática porque remove parte da integração e torna as coisas mais complicadas e difíceis de suportar :)

Apenas pesquisei esse problema e acho que é o lugar apropriado para perguntar sobre quaisquer atualizações. Existe alguma ferramenta / solução existente ou planeja adicionar alguma funcionalidade ao fio?
Por exemplo, meus problemas atuais com npx são:

1. ele baixa o pacote ausente com dependências todas as vezes,
2. ele cria package-lock.json em projetos orientados para Yarn que causa avisos e precisa ser removido manualmente.
   (especificamente acabei de executar npx gatsby new blog https://github.com/gatsbyjs/gatsby-starter-blog )

Ambos os problemas parecem uma combinação perfeita para resolver para fios como @phra já mencionou como seu terceiro ponto.

UPD: Basicamente, a razão principal para ypx que menciono não é a execução binária (o que está totalmente certo com o yarn), mas a capacidade de fazer download automático dos pacotes que pretendo executar.

Eu concordo. Também acho que há uma oportunidade de melhorar a estranha API do NPM
um pouco. Acho que chamar yarn exec COMMAND faria mais sentido do que
yarnx . O empacotador Ruby tinha um comando muito semelhante
https://bundler.io/man/bundle-exec.1.html

Na segunda-feira, 17 de dezembro de 2018 às 14h29, Pavel Prokudin [email protected]
escreveu:

Pesquisei esse problema no Google e acho que é o lugar apropriado para perguntar sobre
quaisquer atualizações. Existe alguma ferramenta / solução existente, ou pretende adicionar alguns
funcionalidade para fio?
Por exemplo, meus problemas atuais com npx são:

1. ele baixa o pacote ausente com dependências todas as vezes,
2. ele cria package-lock.json em projetos orientados a Yarn que causa
   avisos e necessidade de removê-lo com as mãos.
   (especificamente, acabei de executar o novo blog npx gatsby
   https://github.com/gatsbyjs/gatsby-starter-blog)

Ambos os problemas parecem uma combinação perfeita para resolver para fios como @phra
https://github.com/phra já menciona como seu terceiro ponto.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/yarnpkg/yarn/issues/3937#issuecomment-447968558 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AAjhEng6juvpaK4xLx1KrVHccJAytnAfks5u5_CcgaJpZM4OY9aL
.

-
-Forrest

yarn exec já existe (com um significado diferente do que você sugere) 🙂

O novo yarn dlx resolve esse problema?

cc @sandys @arcanis

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

Sim! Para encerrar este problema por enquanto, ainda não descobri se queremos fazer o backport do recurso para a v1 (provavelmente não?).

Não tenho certeza se é um substituto digno. yarn dlx eslint --help leva 2,7 segundos na minha máquina, enquanto npx eslint --help termina em 0,2s. Se alguém chamar muitos scripts bin, isso rapidamente resultará em valores inaceitáveis.

Além disso, acho que stdout / stderr não deve ser escrito pelo yarn, a menos que haja um erro, para permitir a análise da saída do script.

@silverwind, a diferença de tempo parece bastante grande. Isso é reproduzível em várias execuções de forma consistente? Se sim, eu arquivaria um novo problema para investigação, pois certamente não queremos que seja lento.

Com relação a stdout / stderr do Yarn, eu _cheio_ que você pode usar yarn --silend dlx eslint para suprimir todas as saídas não críticas do Yarn. @arcanis pode confirmar este último?

@ light24bulbs por que em particular?

Para todas as pessoas que encontram algum pacote na web, veja que as instruções de instalação envolvem npx something something , mas desejam permanecer no mundo do yarn.

O novo yarn dlx resolve esse problema?

yarn dlx uma substituição exata de s/npx/yarn dlx/ para npx ? Do contrário, isso não resolve o problema.

tente isso
https://www.npmjs.com/package/ynpx

yarn criar & npx & npm init

demonstração

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 ecoar @rulatir , cheguei aqui porque o guia de início rápido do Storybook diz para usar npx para instalá-lo , e eu não tinha uma receita fácil de como encantar o feitiço equivalente com yarn . Se houver um conjunto equivalente de comandos para yarn, devemos publicá-los no site yarn, de forma que a página (em vez deste thread) fique no topo dos resultados de pesquisa do Google por "versão yarn de npx".

Eu também estou no mesmo barco que @codekiln. Sempre que estou seguindo algumas instruções que dizem executar npx ... , não tenho ideia do que é o yarn equivalente. Um exemplo é npx tslint-to-eslint-config .

@ light24bulbs - para ecoar @rulatir , cheguei aqui porque o guia de início rápido do Storybook diz para usar npx para instalá-lo , e eu não tinha uma receita fácil de como encantar o feitiço equivalente com yarn . Se houver um conjunto equivalente de comandos para yarn, devemos publicá-los no site yarn, de forma que a página (em vez deste thread) fique no topo dos resultados de pesquisa do Google por "versão yarn de npx".

O mesmo aqui, com o guia de instalação do capacitorjs https://capacitorjs.com/docs/getting-started , a sensação é que isso convence o usuário a abandonar o fio e voltar ao npm

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

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

404 Página Não Encontrada

Acho que @delanym se referia a esta página (mas não acho que isso replique npx ): https://yarnpkg.com/cli/exec