Cannot find module @rollup/rollup-linux-x64-gnu: გამოსწორება

Error: Cannot find module @rollup/rollup-linux-x64-gnu ნიშნავს, რომ Rollup-ის native binary იმ მანქანისთვის, რომელზეც მუშაობ, არასოდეს დაინსტალირებულა. Rollup 4 თავის parser-ს ცალკე კომპილირებული პაკეტის სახით აწვდის თითოეული პლატფორმისთვის, npm კი მხოლოდ იმას აინსტალირებს, რომელიც ემთხვევა მანქანას. სწორი პაკეტის მოუსვლელობას სამი რამ იწვევს: package-lock.json, რომელიც სხვა ოპერაციულ სისტემაზე დაწერა npm-ის ისეთმა ვერსიამ, სადაც optional dependency-ების ცნობილი ბაგია; სხვა მანქანიდან გადმოკოპირებული node_modules საქაღალდე (ხშირად Docker image-ში); ან ინსტალაცია, რომელიც optional dependency-ების გამორთვით გაეშვა. თითქმის ყოველთვის ის გამოსავალი მუშაობს, რომელსაც თვითონ Rollup გირჩევს: წაშალე node_modules-იც და package-lock.json-იც, თავიდან გაუშვი npm install და ახალი lockfile დააკომიტე. ამ პოსტის დანარჩენი ნაწილი იმაზეა, როგორ გააკეთო ეს ისე, რომ სხვა არაფერი გააფუჭო და შეცდომა შემდეგ deploy-ზე არ დაბრუნდეს.

რას ამბობს შეცდომა სინამდვილეში#

სრული შეტყობინება Rollup-ის საკუთარი loader-იდან მოდის და უჩვეულოდ გულახდილია:

Error: Cannot find module @rollup/rollup-linux-x64-gnu. npm has a bug relatedto optional dependencies (https://github.com/npm/cli/issues/4828). Please try`npm i` again after removing both package-lock.json and node_modules directory.

ყველაზე მნიშვნელოვანი დასაწყისში მოყვანილი პაკეტის სახელია. ის გეუბნება, რომელ პლატფორმაზე ჩათვალა Rollup-მა, რომ მუშაობს, და შესაბამისად რომელ binary-ს დაუწყო ძებნა. სახელს Rollup სამი რამისგან აგებს: ოპერაციული სისტემა, CPU არქიტექტურა და Linux-ზე C ბიბლიოთეკა.

სხვებიც არსებობს - FreeBSD, RISC-V, s390x, 32-ბიტიანი ARM და სხვა - მაგრამ ცხრილი თითქმის ყველა შემთხვევას ფარავს. სუფიქსი თავისთავად დიაგნოზია. თუ შენი სერვერი ჩვეულებრივი x64 Linux-ია, შეცდომაში კი linux-x64-musl წერია, ე.ი. Alpine-ში მუშაობ, ამის გაცნობიერებით თუ მის გარეშე. თუ Windows-ზე ხარ და შეცდომა win32-x64-msvc-ს ასახელებს, ვიღაცის სხვის lockfile-ს იყენებ.

Linux-ზე Rollup gnu-სა და musl-ს შორის გაშვების დროს არჩევს, Node-ის process report-ს ეკითხება: თუ report-ში glibc-ის ვერსიაა, ეს gnu-ა, თუ არა - musl. ამას ვერსად გაწერ და environment ცვლადითაც ვერ გადაფარავ.

რატომ სჭირდება Rollup-ს binary და რატომ მოაქვს მას Vite-ს#

Rollup 3 წმინდა JavaScript იყო. Rollup 4-მა, რომელიც 2023 წლის ოქტომბერში გამოვიდა, თავისი JavaScript parser SWC-ის parser-ით ჩაანაცვლა, რომელიც Rust-იდან native Node add-on-ად არის კომპილირებული. პარსინგი ბევრად სწრაფი გახდა და გაჩნდა პრობლემა, რომელიც ყველა native პაკეტს აქვს: ერთი კომპილირებული ფაილი ყველა პლატფორმაზე ვერ გაეშვება.

Rollup-ის მიერ გამოყენებული სქემა, რომელსაც esbuild, SWC, Lightning CSS, Tailwind CSS 4-ის @tailwindcss/oxide და sharp-ის @img/* პაკეტებიც იყენებენ, ასეთია: თითოეული პლატფორმისთვის ცალკე პატარა პაკეტი ქვეყნდება და ყველა მათგანი მთავარი პაკეტის optionalDependencies-შია ჩამოთვლილი. თითოეული პლატფორმის პაკეტი თავის package.json-ში აცხადებს, რომელ ოპერაციულ სისტემას და CPU-ს უჭერს მხარს (Linux-ის build-ებისთვის კი - რომელ C ბიბლიოთეკას):

{  "name": "@rollup/rollup-linux-x64-gnu",  "os": ["linux"],  "cpu": ["x64"],  "libc": ["glibc"],  "main": "./rollup.linux-x64-gnu.node"}

როცა npm rollup-ს აინსტალირებს, ოც-ოდე optional dependency-ს ხედავს, თითოეულის os და cpu-ს მიმდინარე მანქანას ადარებს, შეუსაბამოებს უხმოდ ტოვებს და ინსტალაციას უკეთებს იმას, რომელიც ემთხვევა. optional ნიშნავს, რომ წარუმატებლობა ან შეუსაბამობა შეცდომა არ არის. სწორედ ამიტომ მუშაობს ეს სქემა სხვადასხვა პლატფორმაზე და სწორედ ამიტომ ფუჭდება უხმოდ, როცა რამე არასწორად მიდის: npm არასოდეს გეტყვის, რომ ის ერთადერთი პაკეტი გამოტოვა, რომელიც გჭირდებოდა.

Rollup-ს უმეტესობა განზრახ არ აინსტალირებს. ის Vite-თან ერთად მოდის. Vite 5, 6 და 7 production build-ებისთვის Rollup 4-ზეა დამოკიდებული, ამიტომ შეცდომა vite build-ზე ჩნდება, ჩვეულებრივ CI job-ში ან სერვერზე და იშვიათად - ლეპტოპზე, სადაც პროექტი მოამზადეს. Vite 4-დან Vite 5-ზე გადასვლა ბევრი პროექტისთვის პირველი შეხვედრის მომენტი იყო, რადგან Vite 4 ჯერ კიდევ Rollup 3-ს იყენებდა და esbuild-ის გარდა საკუთარი პლატფორმული binary-ები არ ჰქონდა.

Vite 8 Rollup-ს Rolldown-ით ცვლის, რომელიც იმავე მექანიზმს სხვა სახელებით იყენებს: @rolldown/binding-linux-x64-gnu და მისთანები. თუ Vite 8-ზე ხარ და Rolldown-ისგან native binding-ის ნაკლებობის შეცდომას ხედავ, ამ პოსტში დაწერილი ყველაფერი შენთვისაც მუშაობს - მხოლოდ პაკეტების სახელები იცვლება.

npm-ის ბაგი, რომელიც უმეტეს შემთხვევას უდევს საფუძვლად#

საკითხი, რომელზეც Rollup ბმულს გვაძლევს, npm/cli#4828, 2022 წლის აპრილში გაიხსნა და აღწერს შემდეგს: როცა npm package-lock.json-ს თავიდან აგენერირებს ისე, რომ node_modules საქაღალდე უკვე არსებობს, lockfile-ს სრული dependency მეტამონაცემებიდან კი არა, იმისგან აგებს, რაც დაინსტალირებულია. Mac-ზე ეს ნიშნავს, რომ lockfile-ში @rollup/rollup-darwin-arm64 აღმოჩნდება და სხვა პლატფორმის არც ერთი პაკეტი, რადგან იქ ისინი არასოდეს დაინსტალირებულა.

შემდეგ ეს lockfile კომიტდება. Linux-ზე npm ci ზუსტად იმას აინსტალირებს, რაც lockfile-შია ჩამოთვლილი - ამაში კი Linux-ის binary არ შედის - და გაფრთხილების გარეშე სრულდება. პრობლემის პირველი ნიშანი build-ია.

ჩვეულებრივი მიზეზი უწყინარია: ვიღაც merge conflict-ის ან peer dependency გაფრთხილების გამო მხოლოდ lockfile-ს წაშლის, node_modules ადგილზე რჩება, npm install-ს გაუშვებს და შედეგს დააკომიტებს. იგივე ხდება Windows-ზეც, ანუ Linux-ზე შექმნილი lockfile საპირისპირო მიმართულებით ამტვრევს Windows-ის დეველოპერებს win32-x64-msvc-ით.

გამოსწორების სურათი ბუნდოვანია. საკითხის კომენტარებში წერია, რომ npm 11-ის ბოლო რელიზები იმ პაკეტებისთვის, რომლებიც ყველა პლატფორმას optional dependency-ად აცხადებენ (Rollup-ის შემთხვევაა), სხვა პლატფორმებს აღარ აგდებენ, სხვა კომენტარები კი აღწერს, რომ პრობლემა 11.x-ის მომდევნო რელიზებში ბრუნდება. npm-ის რომელიმე კონკრეტულ ვერსიაზე იმედს ნუ დაამყარებ. გეგმა იმ lockfile-ზე დააფუძნე, რომელიც თვითონ შეამოწმე.

ცვლილებამდე დაადასტურე მიზეზი#

ორი ბრძანება გეტყვის, სამი მიზეზიდან რომელი გაქვს. პირველი, იმ მანქანაზე, რომელზეც ვარდება, ჰკითხე npm-ს, დაინსტალირებულია თუ არა binary:

$ npm ls @rollup/rollup-linux-x64-gnumy-app@1.0.0 /srv/app└── (empty)

ცარიელი შედეგი ნიშნავს, რომ npm მას ხეში არსად დაუინსტალირებია. შემდეგ თვითონ lockfile-ს შეხედე და პლატფორმების ჩანაწერები დათვალე:

$ grep -c '"node_modules/@rollup/rollup-' package-lock.json1

ჯანმრთელი lockfile Rollup-ის მიერ გამოქვეყნებულ ყველა პლატფორმას ჩამოთვლის, ამიტომ რიცხვი Rollup-ის ვერსიის მიხედვით დაახლოებით ოცია. ერთი ან ორი npm-ის ბაგის ნიშანია: lockfile ერთ მანქანაზე დაგენერირდა და მხოლოდ ამ მანქანის binary-ს იცნობს. იმის სანახავად, რომელს იცნობს:

$ grep '"node_modules/@rollup/rollup-' package-lock.json    "node_modules/@rollup/rollup-darwin-arm64": {

თუ lockfile სრულია და პაკეტი მაინც აკლია, პრობლემა lockfile-ში არ არის. ნახე, როგორ მოხვდა node_modules მანქანაზე და გამორთულია თუ არა optional dependency-ები - ორივეს შემდეგი ნაწილები განიხილავს.

გამოსწორება: lockfile სწორად თავიდან დააგენერირე#

იმ მანქანაზე, სადაც dependency-ებს ჩვეულებრივ ცვლი:

$ rm -rf node_modules package-lock.json$ npm install$ grep -c '"node_modules/@rollup/rollup-' package-lock.json$ git add package-lock.json$ git commit -m "fix: regenerate lockfile with all platform binaries"

Windows-ზე PowerShell-ში პირველი ხაზია Remove-Item -Recurse -Force node_modules, package-lock.json. მთავარი node_modules-ის წაშლაა. მხოლოდ lockfile-ის წაშლა, როცა node_modules ადგილზეა, სწორედ ის რამაა, რაც ბაგს იწვევს.

ამ გამოსწორებას ფასი აქვს და მისი გარკვევით თქმა ღირს. lockfile-ის გარეშე npm install package.json-ის ყველა ვერსიის დიაპაზონს თავიდან ამოხსნის დღეს გამოქვეყნებული ვერსიების მიხედვით. ^5.4.0, რომელიც 5.4.2-ზე იყო დაფიქსირებული, შეიძლება 5.4.19 გახდეს. პროექტების უმეტესობისთვის ეს უვნებელია, მაგრამ არარაობაც არ არის: წაიკითხე lockfile-ის diff, გაუშვი ტესტები და build და deploy გააკეთე როგორც dependency-ების განახლება და არა როგორც ერთხაზიანი გამოსწორება. თუ განახლება უფრო მცირე გჭირდება, შემდეგ ნაწილში უფრო ვიწრო ვარიანტებია.

სერვერზე არაფერი იცვლება, გარდა იმისა, რომ ახლა სწორ lockfile-ს იღებს. იქ npm ci განაგრძე - ის ზუსტად იმას აინსტალირებს, რასაც lockfile ამბობს, და ეს ახლა სწორია. npm ci vs npm install განმარტავს, რატომ არ უნდა იყოს სერვერი მანქანა, რომელიც lockfile-ს წერს. თუ შეცდომის მოსაცილებლად სერვერზე npm install-ზე გადასვლა გაგიჩნდა, ნუ გააკეთებ: არსებულ გაფუჭებულ lockfile-თან ის ხშირად მაინც გამოტოვებს binary-ს, როცა არ გამოტოვებს, ეს იმიტომაა, რომ სერვერზე შენი dependency-ების ხე თავიდან დაწერა.

უფრო ვიწრო გამოსწორებები, როცა ყველაფრის თავიდან დაგენერირება არ შეგიძლია#

ზოგჯერ სრული ხელახალი ამოხსნა მიუღებელია - release branch, audit freeze, monorepo, სადაც ერთი lockfile ორმოც პაკეტს ფარავს. ორი უფრო ვიწრო ვარიანტი არსებობს, ორივეს თავისი კომპრომისით.

ნაკლული binary თვითონ გამოაცხადე. პლატფორმის პაკეტი დაამატე შენი package.json-ის optionalDependencies-ში, ზუსტად იმავე ვერსიით, როგორიც შენს lockfile-ში rollup-ს აქვს:

{  "optionalDependencies": {    "@rollup/rollup-linux-x64-gnu": "4.40.0"  }}

შემდეგ გაუშვი npm install, რომ lockfile-მა ჩაიწეროს. რადგან ის optional-ია, npm მას Mac-ზე გამოტოვებს და Linux-ზე დააინსტალირებს. პრობლემა ვერსიაშია: binary უნდა ემთხვეოდეს Rollup-ის იმ რელიზს, რომელსაც ეკუთვნის, და როცა Vite შემდეგ ჯერზე Rollup-ის უფრო ახალ ვერსიას მოიტანს, შენი pin მოძველდება. მიუდექი როგორც დროებით გამოსავალს და lockfile სწორად თავიდან რომ დააგენერირებ, წაშალე.

გამოიყენე Rollup-ის WebAssembly build. Rollup აქვეყნებს @rollup/wasm-node-ს - იგივე bundler-ს, რომლის parser native კოდის ნაცვლად WebAssembly-შია კომპილირებული. მას პლატფორმული პაკეტები საერთოდ არ აქვს, ამიტომ ამ ტიპის შეცდომა უბრალოდ ქრება. ხეში rollup-ის ყველა ასლი npm override-ით მიმართე მასზე:

{  "overrides": {    "rollup": "npm:@rollup/wasm-node"  }}

დამატების შემდეგ გაუშვი npm install. ფასი სიჩქარეა - WebAssembly-ით პარსინგი native-ზე შესამჩნევად ნელია, რაც დიდ build-ებზე იგრძნობა და პატარებზე თითქმის არა. ეს გონივრული არჩევანია იმ პლატფორმებისთვის, რომლებზეც Rollup-ს native build არ აქვს, და გუნდებისთვის, რომლებიც მყიფე build-ს ნელი build-ის არჩევენ.

node_modules, მანქანებს შორის გადაკოპირებული, და Docker#

მეორე მიზეზს npm-ის ბაგთან კავშირი არ აქვს. ერთ პლატფორმაზე დაინსტალირებული node_modules საქაღალდე მხოლოდ ამ პლატფორმის binary-ს შეიცავს, ამიტომ სხვა პლატფორმაზე გადატანისას ახალ მანქანას თავისი binary აკლია. lockfile შეიძლება იდეალური იყოს და ეს მაინც მოხდეს.

გავრცელებული გზები:

• პროექტის საქაღალდის ატვირთვა `node_modules`-ით, SFTP-ით ან zip-ად. Mac-ზე დაინსტალირებული საქაღალდე darwin-arm64-ს ატარებს და Linux-ისთვის არაფერს.
• `node_modules`-ის Git-ში დაკომიტება. ის ყოველთვის .gitignore-ში უნდა იყოს - დიდია, პლატფორმაზეა მიბმული და lockfile-იდან წამებში თავიდან აიგება.
• Docker-ის `COPY . .` `npm ci`-ის შემდეგ. ეს კლასიკური შემთხვევაა. image სწორ Linux binary-ს აინსტალირებს, შემდეგი ხაზი კი შენი ლეპტოპის node_modules-ს მის თავზე გადააკოპირებს.

Dockerfile-ის სქემა, რომელიც ამას თავიდან იცილებს, ჯერ მხოლოდ manifest ფაილებს აკოპირებს, ინსტალაციას image-ის შიგნით აკეთებს და წყაროს ბოლოს აკოპირებს:

FROM node:22-bookworm-slim AS buildWORKDIR /appCOPY package.json package-lock.json ./RUN npm ciCOPY . .RUN npm run build

ეს მარტო საკმარისი არ არის, რადგან COPY . . ლოკალურ node_modules-ს მაინც გადააკოპირებს, თუ ის არსებობს. Dockerfile-ის გვერდით მდებარე .dockerignore ფაილი ამას აჩერებს:

node_modulesdist.git

ის build-ებსაც აჩქარებს, რადგან Docker აღარ აგზავნის ასობით მეგაბაიტ build context-ს, რომელსაც მაინც გადააგდებდა.

Docker Compose-ის სადეველოპმენტო გარემოებს ამის საკუთარი ვერსია აქვს. bind mount, როგორიცაა .:/app, image-ის /app-ს შენი პროექტის საქაღალდით ცვლის, შენი ლეპტოპის node_modules-ის ჩათვლით. ჩვეულებრივი გამოსწორებაა ანონიმური volume ამ საქაღალდისთვის, რომელიც კონტეინერის საკუთარ ასლს ინახავს:

services:  web:    build: .    volumes:      - .:/app      - /app/node_modules

Docker VDS-ზე და Docker Compose პატარა stack-ებისთვის უფრო ფართო სქემებს განიხილავს.

Alpine, musl და ARM#

Alpine-ზე დაფუძნებული image-ები glibc-ის ნაცვლად musl-ს იყენებენ, ამიტომ Rollup linux-x64-musl-ს ითხოვს. სრული lockfile-ისა და Alpine image-ის შიგნით გაშვებული ინსტალაციის შემთხვევაში ეს უბრალოდ მუშაობს: npm musl build-ს ირჩევს. ის ფუჭდება, როცა ინსტალაცია სხვაგან გაეშვა - Debian-ზე ან CI runner-ზე აგებული და Alpine-ის stage-ში გადაკოპირებული node_modules linux-x64-gnu-ს შეიცავს, Alpine-ში Rollup კი მას ვერ ჩატვირთავს. წესი იგივეა, რაც ყველა სხვა შემთხვევაში: npm ci გაუშვი იმავე image-ში, ან სულ მცირე იმავე base-ზე, რომელზეც build გადის.

თუ Alpine-ის გამოყენების ძლიერი მიზეზი არ გაქვს, Debian-ზე დაფუძნებული image, მაგალითად node:22-bookworm-slim, native მოდულების გასაკვირი პრობლემების მთელ კატეგორიას აქრობს, სანაცვლოდ image ცოტა დიდია.

ARM-ს ხალხი Apple Silicon-ით ხვდება. Docker M-სერიის Mac-ზე ნაგულისხმევად linux/arm64 image-ებს აგებს, ამიტომ build-ის შიგნით ინსტალაცია linux-arm64-gnu-ს იღებს. ასეთი image x64 სერვერზე Rollup-ის გარდა ბევრი მიზეზის გამო არ გაეშვება. build მიზნობრივი პლატფორმისთვის პირდაპირ მიუთითე:

$ docker build --platform linux/amd64 -t my-app .

მსგავსად გამოიყურება, მაგრამ npm-ის ბაგი არ არის სხვა შეცდომა. თუ stack trace-ში მსგავსი რამ წერია, როგორიცაა GLIBC_2.xx not found, binary დაინსტალირდა, მაგრამ სისტემის C ბიბლიოთეკა ძალიან ძველია მის ჩასატვირთად - ჩვეულებრივ ძალიან ძველი build image-ია. ხელახლა ინსტალაციის ნაცვლად base image განაახლე.

optional dependency-ები არ გამორთო#

მესამე მიზეზი საკუთარი ხელით შექმნილია. npm ci --omit=optional, უფრო ძველი --no-optional, omit=optional .npmrc-ში ან NPM_CONFIG_OMIT=optional CI გარემოში npm-ს ყველა optional dependency-ის გამოტოვებას ეუბნება - Rollup-ის binary-ის ჩათვლით, რომელიც მხოლოდ იმ აზრით არის optional, რომ npm-მა ერთ-ერთი უნდა აირჩიოს. Rollup მერე ზუსტად ისე ვარდება, თითქოს ბაგი დაგეცა.

ეს პარამეტრები ხშირად image-ების შესამცირებელი ძველი გაკვეთილიდან ან სხვა პაკეტის გაფუჭებული install script-ის გვერდის ავლიდან მოდის. შეამოწმე, რას იყენებს npm სინამდვილეში:

$ npm config get omit

ის არაფერს უნდა ბეჭდავდეს, ან dev-ს, თუ dev dependency-ებს განზრახ გამოტოვებ. ამ გამოტანაში optional პრობლემაა. გაითვალისწინე ცალკე მახე: Vite და Rollup devDependencies-ია, ამიტომ npm ci --omit=dev, რასაც vite build მოჰყვება, ასევე ვარდება, ოღონდ ამ შეცდომით კი არა, vite: not found-ით. დააინსტალირე ყველაფერი, გააკეთე build და მერე npm prune --omit=dev-ით გაასუფთავე.

ჰოსტინგის აპლიკაციის სერვერზე#

კონტეინერებზე დაფუძნებულ ჰოსტზე იგივე წესები მოქმედებს და ერთადერთი რეალური გადაწყვეტილება ისაა, სად გადის build. RE:NODE-ზე Node.js აპლიკაციების გეგმები GitHub-იდან panel-ის Git deploy-ით ადეპლოიდება და როცა შენი start command npm ci-ს და build-ს უშვებს, ისინი სერვერზე სრულდება - ამიტომ lockfile, რომელიც Rollup-ის ყველა პლატფორმას ჩამოთვლის, მთელი გამოსწორებაა: დააკომიტე და თავიდან გააკეთე deploy. panel-ის კონსოლი ინსტალაციისა და build-ის გამოტანას ფილტრის გარეშე აჩვენებს, ამიტომ ნაკლული binary უხმო crash-ის კი არა, ზემოთ მოყვანილი შეცდომის სახით ჩნდება - კონსოლის კითხვა განმარტავს, რას უნდა დააკვირდე. ლოკალური node_modules file manager-ით ან SFTP-ით ნუ ატვირთავ; დაე npm ci-მ ააგოს ის სერვერზე.

თუ სერვერი განუწყვეტლივ ირესტარტება, რადგან start command-ის შიგნით build ვარდება, ხელახლა გადატვირთვამდე lockfile გაასწორე. watcher crash-restart-ებს ითვლის: საათში სამი სერვერის გვერდზე გაფრთხილებას აჩენს და ticket-ს ხსნის, ექვსი სერვერს აჩერებს. Node აპლიკაციის deploy GitHub-იდან start command-სა და build-შემდეგ-prune თანმიმდევრობას აჩვენებს. თუ შენი Vite პროექტი უბრალო სტატიკურ ფაილებად იგება, runtime-ზე Node საერთოდ არ გჭირდება - build CI-ში გააკეთე და dist საქაღალდე გასცი, რასაც სტატიკური საიტის ჰოსტინგი განიხილავს.

FAQ#

რატომ მუშაობს build ჩემს ლეპტოპზე და სერვერზე არა?

შენს ლეპტოპს თავისი პლატფორმის binary აქვს, რომელიც პირველი npm install-ისას დაინსტალირდა. სერვერს სხვა სჭირდება და ან lockfile-ში არ არის, ან რაღაცამ npm-ს ინსტალაცია შეუშალა. ზემოთ მოყვანილი grep -c შემოწმება გეტყვის, რომელია.

სერვერზე node_modules-ის წაშლა გაასწორებს?

არა, თუ პრობლემა lockfile-შია. npm ci მაინც შლის node_modules-ს და lockfile-იდან თავიდან აინსტალირებს, ამიტომ Linux-ის binary-ს მოკლებული lockfile ყოველ ჯერზე ერთსა და იმავე შედეგს იძლევა. lockfile თავიდან უნდა დაგენერირდეს და დაკომიტდეს.

უნდა დავაინსტალირო @rollup/rollup-linux-x64-gnu ჩვეულებრივ dependency-ად?

არა. ჩვეულებრივი dependency optional არ არის, ამიტომ ინსტალაცია ყველა Mac და Windows მანქანაზე EBADPLATFORM შეცდომით სრულად ვარდება. თუ დროებითი გამოსავალი გჭირდება, optionalDependencies-ში ჩაწერე Rollup-ის ზუსტ ვერსიაზე.

pnpm ან Yarn თავიდან აგვაცილებს ამას?

lockfile-ის კონკრეტული ბაგი npm-ისაა, ამიტომ პაკეტების მენეჯერის შეცვლა ხშირად პრობლემას აქრობს. node_modules-ის პლატფორმებს შორის გადაკოპირება და optional dependency-ების გამორთვა კი ყველა პაკეტების მენეჯერს ერთნაირად ტეხავს, ამიტომ Docker-ისა და .dockerignore-ის რჩევა მაინც მოქმედებს.

იგივე დგას esbuild-ისა და SWC-ის პლატფორმულ შეცდომებშიც?

დიახ, მექანიზმი იდენტურია: თითო optional პაკეტი თითო პლატფორმაზე. esbuild-ის შეტყობინება განსხვავებულია - ამბობს, რომ esbuild სხვა პლატფორმისთვის დააინსტალირე, ვიდრე ის, რომელსაც იყენებ - მაგრამ გამოსწორებები იგივეა: სრული lockfile, ინსტალაცია სამიზნე პლატფორმაზე და გადაკოპირებული node_modules-ის გარეშე.