그만한 가치가 있기 때문에 npx는 유사하지만 "create-" 접두사가 붙은 패키지에서만 작동하는 "yarn create"에서 영감을 얻었다고 생각합니다. 여기에 어떤 계획이 있는지 확실하지 않습니다.

예, 현재 yarn create (예 yarn create react-app 사용해 보십시오). 미래에 다른 동사에게 공개할 수도 있지만 아직 로드맵에는 없습니다.

npx를 라이브러리화하는 작업을 하고 있습니다. 기존 npx 코드를 잡고 npm 관련 내장을 yarn에 해당하는 명령으로 바꾸는 것은 큰 작업이 아닙니다.

npx 자체에 직접 추가하지 않겠습니다. 왜냐하면 불가지론적이어야 _의미하기 때문입니다. npx는 다른 패키지 관리자를 사용하는 사람들과 충돌하는 작업을 수행하지 않습니다. 시스템에 npm이 있을 필요도 없으므로 npm rm -g npm 하면 npx가 제대로 작동합니다. 따라서 캐시 공유에 대해 강하게 느끼지 않는 한 npx _is_ ypx 라고 말할 수 있습니다.

(재 영감: npx는 주로 이 오랜 기능 요청에서 영감을 받았습니다: https://github.com/npm/npm/issues/6053. 대부분의 기능은 _this_ 필요를 충족하는 데 중점을 둡니다. 자동 설치 기능이 _was_ 추가되었습니다. post-yarn-create, 그리고 확실히 그 특정한 것에 대한 실제 일반화된 솔루션이 되도록 의도되었습니다 -- 그러나 그것은 _훨씬 더_ 합니다)

@sandys -에 참조 @zkat 문제 (NPM / NPM # 6053)이 아닌 문제 yarn 당신은 그냥 할 수 있기 때문에 yarn x (또는 yarn run x 당신이 원하는 경우 명시적) x 가 ./node_modules/.bin 디렉토리에 있는 경우. 따라서 npx 동등성에 대한 긴급한 필요성이 있다고 생각하지 않습니다.

강력한 필요성이 있다고 생각한다면 왜 필요한지 설명할 수 있습니까? 예. 어떤 문제가 해결될까요?

yarn exec 가 bundle exec 와 비슷한지 아는 사람이 있습니까? CLI에서는 볼 수 있지만 웹 사이트의 문서에서는 볼 수 없습니다. 명령줄에서 yarn exec 를 사용하면 설치된 바이너리를 실행하는 것처럼 보이므로 @sandys 문제를 해결할 수 있습니다.

FWIW, npm-run 은 로컬 node_modules 바이너리를 실행할 수 있게 해주는 이전 유틸리티이며 npm 에 의존하지 않습니다. 옵션이 없지만 npx 는 노브로 가득 차 있습니다.

@BYK 사용 사례가 프로젝트 자체에 deps로 추가하지 않고 CI에서 ypx greenkeeper-lockfile@1 또는 ypx danger@2 와 같이 실행 중입니다.

@SimenB CI는 일반적으로 프로젝트를 버전 제어에 다시 커밋하지 않으므로 프로세스에 종속성을 추가해도 상관 없습니다.

@MarkBennett yarn exec 는 package.json 에서 스크립트를 실행하지 않기 때문에 이 기능을 추가하는 것이 적절하지 않다고 생각합니다.

@BYK 나는 OP가 아니지만 내 로컬 컴퓨터에는 패키지가 있지만 내 package.json에는 없기 때문에 이 기능을 요청하게 되었습니다. 따라서 내 앱은 나를 위해 실행되지만 내 앱을 새로 설치한 사람에게는 실행되지 않습니다. 이것은 내가 좋아하는 ruby ​​번들러의 bundle exec 입니다. 모든 dep가 매니페스트에 없으면 실행되지 않습니다.

yarn x 에 대한 나의 주요 불만은 3개의 다른 위치(얀 내부 명령, npm 스크립트 및 저장소)에서 대상을 해결하려고 한다는 것입니다.

check 라는 바이너리가 있는 도구가 있다고 가정해 보겠습니다. 1) yarn check 는 대신 자체 내부 check 명령을 실행합니다. 2) yarn run check 는 소비자의 npm을 실행합니다. 그런 이름을 가진 스크립트나 내 도구일 수도 있습니다.

npx 는 강력한 개념 분리를 제공합니다. yarn x 는 항상 내부 명령이고, yarn run x 는 항상 스크립트이며, npx x 는 항상 바이너리이며 필요하지 않습니다. 추측하고 희망합니다.

요지 같은 것

#!/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 또 다른 사용 사례는 아직 로컬에 설치되지 않은 패키지의 _binary_를 실행하고 있으며 나중에 직접 삭제하지 않고 한 번만 실행하고 싶습니다. npx 함수는 다음을 수행할 수 있기 때문에 yarn x 동작의 확장입니다.

1. 현재 디렉토리의 ./node_modules/.bin/ 에서 로컬 패키지의 명령을 실행합니다.
2. 패키지가 로컬에 없거나 ./node_modules/ 디렉토리가 존재하지 않는 경우 종속성과 함께 임시 디렉토리에 패키지를 다운로드하고 명령을 호출합니다.

이것은 사용자에게 투명하게 수행됩니다.

ypx 가설은 다음과 같은 세 번째 요점도 제공할 수 있습니다.

1. 패키지가 로컬에 없고 얀 캐시에 있고 최신 버전과 일치하는 경우 모든 패키지를 다운로드하는 대신 캐시를 사용하여 명령을 호출합니다.

@BYK 작동하지 않습니다.
babel-cli 설치(예: yarn add babel-cli
그런 다음 yarn babel-node --presets es2015 ./server.js 를 실행합니다. server.js 는 현재 디렉토리에 있는 파일이고 간단한 express API 서버입니다.
그것은 단순히 작동하지 않으며 파일이 존재하지 않는다고 말합니다. ( Error: Cannot find module )
그러나 함께 사용 npx 작동 npx babel-node --presets es2015 ./server.js

@BYK 내가 아는 한 npx는 로컬 시스템의 node_module/.bin/ 에서 명령을 찾고 적절한 명령을 찾지 못하면 웹에서 패키지를 가져오고 항상 최신 상태를 유지할 수 있습니다. .
yarn은 로컬 컴퓨터에 설치되어 있지 않은 동안 웹에서 패키지를 가져오지 않습니다.

yarnx 받을 수 있나요?

@light24bulbs 특히 왜?

솔직히 저는 npx 가 약간 너무 "npm inc." 중심적이긴 하지만 좋은 도구라고 생각합니다. yarnx 는 이 문제를 해결하지 못하므로(필연적으로 원사 중심이어야 함) 이것이 좋은 생각인지 확신할 수 없습니다.

이상적으로는 사용할 패키지 관리자를 자동으로 감지하거나 최소한 rc 파일 내에서 구성할 수 있도록 npx 를 사용하는 것이 좋습니다. 나는 이 문제를 그들에게 가져오고 그들이 말하는 것을 볼 것을 제안하고 싶습니다. 답변에 따라 정보에 입각한 토론을 할 수 있습니다 🙂

@arcanis npx 자체는 npm과 함께 번들로 제공되기 때문에 npm과 결합됩니다 -- libnpx 는 그렇지 않으며 실제로 pnpm의 pnpx 가 후드 아래에서 사용합니다. Zoltan을 가능하게 하기 위해 몇 가지 패치를 추가했습니다. 일부 통합을 제거하고 지원하기가 더 복잡하고 어렵게 만들기 때문에 자동 감지 지원을 추가하지 않겠습니다. :)

방금 이 문제를 검색했는데 업데이트에 대해 물어볼 수 있는 적절한 장소라고 생각합니다. 기존 도구/솔루션이 있습니까? 아니면 원사에 일부 기능을 추가할 계획입니까?
예를 들어 npx에 대한 현재 문제는 다음과 같습니다.

1. 매번 의존성이 있는 부재 패키지를 다운로드합니다.
2. 경고를 발생시키고 손으로 제거해야 하는 Yarn 지향 프로젝트에서 package-lock.json을 생성합니다.
   (특히 방금 npx gatsby new blog https://github.com/gatsbyjs/gatsby-starter-blog )

이 두 가지 문제는 @phra가 이미 세 번째 요점으로 언급한 것과 같은 원사를 해결하기 위해 완벽하게 일치하는 것처럼 보입니다.

UPD: 기본적으로 내가 언급한 ypx 주된 이유는 바이너리 실행(원사를 사용하면 전혀 문제 없음)이 아니라 실행하려는 패키지를 자동 다운로드하는 기능입니다.

나는 동의한다. NPM 이상한 API를 개선할 기회도 있다고 생각합니다.
약간. yarn exec COMMAND 호출하는 것이
yarnx . Ruby 번들러에는 매우 유사한 명령이 있습니다.
https://bundler.io/man/bundle-exec.1.html

2018년 12월 17일 월요일 오후 2시 29분 Pavel Prokudin [email protected]
썼다:

방금 이 문제를 구글링했는데 여기에 대해 질문하기에 적절한 곳이라고 생각합니다.
모든 업데이트. 기존 도구/솔루션이 있거나 일부를 추가할 계획이 있습니까?
실에 기능?
예를 들어 npx에 대한 현재 문제는 다음과 같습니다.

1. 매번 의존성이 있는 부재 패키지를 다운로드합니다.
2. Yarn 지향 프로젝트에서 package-lock.json을 생성하여
   경고 및 손으로 제거해야 합니다.
   (특히 npx gatsby new blog를 실행합니다.
   https://github.com/gatsbyjs/gatsby-starter-blog)

이 두 가지 문제는 모두 @phra와 같은 원사를 해결하는 데 완벽한 일치처럼 보입니다.
https://github.com/phra는 이미 그의 세 번째 요점으로 언급하고 있습니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/yarnpkg/yarn/issues/3937#issuecomment-447968558 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AAjhEng6juvpaK4xLx1KrVHccJAytnAfks5u5_CcgaJpZM4OY9aL
.

--
-포레스트

yarn exec 이미 존재합니다(당신이 제안한 것과 다른 의미로) 🙂

새로운 yarn dlx 이 이 문제를 해결합니까?

cc @sandys @arcanis

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

네! 지금은 이 문제를 끝내고 기능을 v1으로 백포트할지 여부를 아직 파악하지 못했습니다(아마도 그렇지 않습니까?).

대체할만한 가치가 있는지 잘 모르겠습니다. yarn dlx eslint --help 는 내 컴퓨터에서 2.7초가 걸리는 반면 npx eslint --help 는 0.2초 안에 완료됩니다. 많은 bin 스크립트를 호출하면 허용할 수 없는 값이 빠르게 추가됩니다.

또한 스크립트의 출력을 구문 분석할 수 있도록 오류가 없는 한 stdout/stderr을 원사로 작성해서는 안 된다고 생각합니다.

@silverwind 타이밍 차이가 꽤

Yarn의 stdout/stderr과 관련하여 저는 yarn --silend dlx eslint 를 사용하여 중요하지 않은 모든 Yarn 출력을 억제할 수 있다고 _생각_합니다. @arcanis 이 마지막 것을 확인할 수 있습니까?

@light24bulbs 특히 왜?

웹에서 패키지를 찾는 모든 사람들의 경우 설치 지침에 npx something something 되어 있지만 실 세계에 남아 있기를 원합니다.

새로운 yarn dlx 이 이 문제를 해결합니까?

가 yarn dlx 정확한 s/npx/yarn dlx/ 드롭 인 교체 npx ? 그렇지 않으면 이 문제가 해결되지 않습니다.

이 시도
https://www.npmjs.com/package/ynpx

원사 생성 및 npx 및 npm 초기화

데모

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는 - 때문에 에코 @rulatir에, 나는 여기에있어 동화의 빠른 시작 가이드는 사용 말한다 npx 설치하기 위해 , 나는에 해당하는 마법 incant하는 방법에 대한 쉬운 조리법이 없었다 yarn . 원사에 대한 동등한 명령 집합이 있는 경우 해당 페이지(이 스레드 대신)가 "npx의 원사 ​​버전"에 대한 Google 검색 결과의 맨 위에 있도록 이를 원사 웹사이트에 게시해야 합니다.

저도 @codekiln과 같은 배를 타고 있습니다. run npx ... 라는 지침을 따를 때마다 yarn 해당하는 것이 무엇인지 전혀 모릅니다. 예는 npx tslint-to-eslint-config 입니다.

@ light24bulbs는 - 때문에 에코 @rulatir에, 나는 여기에있어 동화의 빠른 시작 가이드는 사용 말한다 npx 설치하기 위해 , 나는에 해당하는 마법 incant하는 방법에 대한 쉬운 조리법이 없었다 yarn . 원사에 대한 동등한 명령 집합이 있는 경우 해당 페이지(이 스레드 대신)가 "npx의 원사 ​​버전"에 대한 Google 검색 결과의 맨 위에 있도록 이를 원사 웹사이트에 게시해야 합니다.

여기에서도 마찬가지로 capacitorjs 설치 가이드 https://capacitorjs.com/docs/getting-started 를 사용 하면 사용자가 원사를 포기하고 npm으로 돌아가도록 설득한다는 느낌을 받습니다.

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

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

404 페이지를 찾을 수 없습니다

@delanym 이 이 페이지를 의미했다고 생각합니다(그러나 이것이 npx 복제한다고 생각하지 않습니다): https://yarnpkg.com/cli/exec