npm, yarn, pnpm, bun: jedna komenda, cztery zapisy
Otwierasz README a tam `pnpm install`. Twój projekt jest na npm. Zaczynasz zgadywać: `npm install`? `npm i`? Z `-D` czy `--save-dev`? Ten sam problem w drugą stronę, napisałeś tutorial dla npm, a czytelnik na bun pyta „a jak to wygląda u mnie".
Ten tłumacz robi nudną robotę. Wybierasz menedżer źródłowy, wpisujesz komendę, którą znasz (`npm install --save-dev typescript`, `yarn add react`, `pnpm dlx create-next-app`...) i dostajesz dokładne odpowiedniki dla wszystkich 4 menedżerów w jednym widoku. Czasowniki, flagi, nazwy paczek, wszystko zmapowane.
To czysty słownik, żadna komenda nie wykonuje się w przeglądarce, nic nie wychodzi z tej strony. Otwórz DevTools i sprawdź. Przydaje się przy migracji z yarn na pnpm, przy utrzymaniu dokumentacji w wielu wariantach albo po prostu kiedy chcesz przypomnieć sobie „jak się odinstalowuje paczkę w bun".
Jak używać
- Wybierz menedżer źródłowy w pasku na górze: npm, yarn, pnpm albo bun. To informacja, w czyjej składni napisana jest Twoja komenda.
- Wpisz komendę w polu wejściowym. Pełna forma (`npm install --save-dev typescript`) albo skrót (`npm i -D typescript`). Nazwę menedżera na początku możesz pominąć, `add react` zadziała tak samo jak `yarn add react`.
- Tłumacz rozpoznaje czasownik (install, add, remove, run, dlx, init, audit, update, outdated) i zachowuje nazwę paczki oraz wszystkie flagi w prawidłowej składni dla każdego menedżera.
- Czytasz 4 wiersze wyniku poniżej: każdy wiersz to jeden menedżer (npm / yarn / pnpm / bun) z komendą-odpowiednikiem. Kliknij kopiuj żeby wrzucić ją do schowka.
- Dla jednorazowego uruchomienia binarki (rodzina `npx`/`yarn dlx`/`pnpm dlx`/`bunx`) wpisz `npx create-next-app`, dostaniesz `yarn dlx create-next-app`, `pnpm dlx create-next-app`, `bunx create-next-app`.
- Zjedź niżej do tabeli ściągi: 11 najczęstszych akcji w jednym widoku, do szybkiego rzutu okiem kiedy potrzebujesz tylko przypomnienia.
- Nic się nie wykonuje, to czysty tłumacz tekstowy. Żeby naprawdę uruchomić komendę, wklej ją do swojego terminala.
Kiedy się przydaje
Sześć typowych sytuacji, w których tłumacz oszczędza Ci wycieczki na StackOverflow:
- Migrujesz projekt z jednego menedżera na inny. Przenosisz projekt z yarn classic na pnpm, bo twarde linki pnpm oszczędzają 5 GB na `node_modules`. Każdy `yarn install`, `yarn add`, `yarn dev` w README, CI, skryptach i pamięci mięśniowej zespołu musi dostać odpowiednik. Wklejasz hurtem i przepisujesz dokumentację w jednym posiedzeniu.
- Idziesz za tutorialem napisanym dla innego menedżera. Dokumentacja Next.js mówi `npx create-next-app`. Ty używasz bun. Wpisujesz `npx create-next-app` w tłumaczu i kopiujesz `bunx create-next-app` prosto do terminala. Bez zgadywania.
- Utrzymujesz dokumentację open source dla wielu menedżerów. README Twojej biblioteki ma pokazywać `npm install` i `yarn add` i `pnpm add` i `bun add` obok siebie. Tłumacz daje Ci wszystkie 4 w jednym wierszu, kopiujesz do dokumentacji i jest spójnie.
- Wprowadzasz nowego developera, który zna yarn, ale wpadł do zespołu na npm. Dajesz mu link do tłumacza. W ciągu dnia ma w głowie tabelę konwersji dla 10 komend, których naprawdę używa.
- Skrypty między zespołami w monorepo. Frontend na pnpm, backend na npm, infra na yarn. Tłumacz pomaga Ci napisać jednolinijkowca, którego wszystkie 3 zespoły potrafią przeczytać.
- Piszesz wpis na blogu albo odpowiedź na Stack Overflow. Piszesz komendę w swoim ulubionym menedżerze, a pod spodem wklejasz tabelę ściągi, żeby każdy czytelnik znalazł swój wariant i nie marudził w komentarzach.