وائٹ کی تشخیص کیسے کریں: کنٹینر کی تعمیر میں npm ci نہیں ملا

از /

میں نے حال ہی میں ایک پروجیکٹ پر کام کیا جہاں Node.js ایپلی کیشن Vite کا استعمال کرتے ہوئے فرنٹ اینڈ کے ساتھ مرتب کی گئی تھی۔ اس نے براؤزر کی میزبانی والے ترقیاتی ماحول میں کام کیا، لیکن Azure کنٹینر رجسٹری میں جانے کے بعد، تصویر کی تعمیر ناکام ہو گئی۔ تعمیر نے اطلاع دی ہے کہ پچھلی انحصار کی تنصیب ناکام ہونے کے بعد وائٹ ایگزیکیوٹیبل غائب تھا۔

کنٹینر کی تعمیر ایک عام غلطی کے ساتھ ختم ہوئی۔

sh: 1: vite: not found

Vite پہلے سے ہی یہاں ہے. devDependencies. تعمیر کا مرحلہ چل چکا ہے۔ npm ci بلڈ اسکرپٹ کو کال کرنے سے پہلے۔ Dockerfile سادہ لگ رہا تھا، لہذا پہلی وضاحت انحصار کے انتخاب کے بارے میں تھی یا NODE_ENV.

غائب بائنری پچھلی خرابی کی وجہ سے ہوئی تھی۔ npm ci ہم نے ایک پیکیج ہوسٹ سے سیکڑوں ٹربالز ڈاؤن لوڈ کرنے کی کوشش کی جو صرف براؤزر پر مبنی ترقیاتی ماحول میں موجود تھے۔ میں نے اسے پرنٹ کیا۔ Exit handler never called!چھوڑ دیا node_modules یہ خالی تھا اور ڈوکر کو واضح ناکامی کی حیثیت فراہم نہیں کرتا تھا۔ آپ اگلی پرت پر پہنچ گئے ہیں۔ npm run build مطلوبہ پہلی گمشدہ قابل عمل فائل کی اطلاع دی۔

لاک فائل نے ناقابل رسائی میزبان پر npm کی طرف اشارہ کیا۔ یہ ٹیوٹوریل آپ کو دکھاتا ہے کہ انسٹالیشن کامیاب ہونے کی تصدیق کیسے کی جائے، متاثرہ ٹربال یو آر ایل تلاش کریں، اور اپنی درخواست کو مرتب کرنے سے پہلے انحصاری درجہ بندی کو چیک کریں۔ مرمت کرنے سے عوامی پیکیج یو آر ایل کا سابقہ ​​تبدیل ہو جاتا ہے اور بلڈ چیکز شامل ہو جاتے ہیں۔ پیکیج کے ورژن، سالمیت کی قدریں، ایپلیکیشن کوڈ، اور وائٹ کنفیگریشن وہی رہے گی۔

انڈیکس

اس سے پہلے کہ آپ شروع کریں۔

آپ کو ایک Node.js پروجیکٹ کی ضرورت ہوگی۔ package.jsonورژن 2 یا 3 package-lock.jsonکنٹینر کی تعمیر کے نوشتہ جات اور ڈوکر۔ یہ مثال وائٹ پروجیکٹ کا استعمال کرتی ہے، جو تعاون یافتہ نوڈ 24 امیجز بناتا ہے اور آؤٹ پٹ بناتا ہے۔ dist. اپنی انحصار کی مطابقت اور آؤٹ پٹ ڈائریکٹریز کو چیک کریں۔

یو آر ایل کو تبدیل کرنے سے پہلے، چیک کریں کہ آیا متاثرہ پیکج پبلک یا پرائیویٹ رجسٹری سے آیا ہے۔ کہ .invalid ذیل میں میزبان کے نام اصل اندرونی میزبانوں کی نمائندگی کرتے ہیں۔ دستیاب پیکیجز کا جائزہ لینے کے بعد ہی اس سابقہ ​​کو ایڈجسٹ کریں۔

تعمیر ناکامی تک کیسے پہنچی۔

ایپلیکیشن کو براؤزر کے زیر اہتمام ترقیاتی ماحول سے بھیجا گیا تھا اور بعد میں Azure کنٹینر رجسٹری کی تعمیر میں منتقل کیا گیا تھا۔ ترقیاتی پلیٹ فارم نے عوامی این پی ایم پیکجوں کے لیے پراکسی کے طور پر کام کیا۔ جب دوبارہ پیدا ہوتا ہے۔ package-lock.jsonاپنا اندرونی ٹربال URL بنائیں resolved بیٹری

غلطی دو ماحول میں ہوئی۔

  1. آپ کے ترقیاتی ماحول کے اندر، npm پیکیج پراکسی تک رسائی حاصل کر سکتا ہے۔ لاک فائل میں وہ پراکسی یو آر ایل تھا۔

  2. Azure کنٹینر رجسٹری امیج بلڈر کو وہی لاک فائل موصول ہوئی لیکن وہ پراکسی ہوسٹ نام کو حل کرنے سے قاصر تھا۔

  3. انحصار کی تنصیبات پرنٹ کی جاتی ہیں۔ Exit handler never called! اور چھوڑ دیا node_modules مفت اس واقعے میں ناکامی کی حالت نے اگلی ڈوکر پرت کو رکنے سے روک دیا۔

  4. اگلی پرت کو پھانسی دے دی گئی ہے۔ npm run buildاسے Vite کہا جاتا تھا۔ اگر کوئی وائٹ ایگزیکیوٹیبل انسٹال نہیں کیا گیا تھا، تو تعمیر کی اطلاع دی گئی۔ vite: not found.

نیچے کی جانچ لاپتہ قابل عمل سے لے کر پیکیج کے مقام تک سلسلہ کو پیچھے کی طرف لے جاتی ہے، پھر یو آر ایل کی مرمت کرتا ہے اور ہر آزاد تنصیب کو محفوظ بناتا ہے۔

تصویر 1. کنٹینر کی تعمیر نے سلسلہ میں آخری ناکامی کی اطلاع دی۔

مرحلہ 1: چیک کریں کہ آیا npm ci کوئی بھی چیز انسٹال ہے۔

منصوبے کا استعمال کیا npm ciیہ دوبارہ قابل کنٹینر کی تعمیر کے لئے صحیح کمانڈ تھا۔ npm کی دستاویزات کا کہنا ہے کہ یہ کمانڈ موجودہ اندراجات کو ہٹاتا ہے۔ node_modules یہ انسٹالیشن شروع کرنے سے پہلے کی ڈائرکٹری ہے۔ یہ لاک فائل کو اپ ڈیٹ کرنے کے بجائے منجمد سمجھتا ہے۔

یہ خصوصیات اس ناکامی کو بہت واضح کرتی ہیں۔ عمارتوں کو پچھلی مقامی تنصیب کے پیکجوں سے تبدیل نہیں کیا جا سکتا۔ اگر ٹربال ڈاؤن لوڈ ناکام ہوجاتا ہے تو، انحصار ڈائرکٹری میں کچھ بھی مفید نہیں ہوگا۔

ڈوکر فائل نے ماخذ کی تالیف سے انحصار کی تنصیب کو الگ کیا۔ مرحلہ 3 اصل ترتیب کا موازنہ ترمیم شدہ تعمیر سے کرتا ہے۔

بعد میں vite: not found پیغام میں یہ نہیں بتایا گیا کہ آیا npm نے پیکیج انسٹال کیا ہے۔ اسی ماحول میں انحصار ڈائرکٹری کے ساتھ شروع کریں جو ناکام ہوگئی۔

test -d node_modules && find node_modules -mindepth 1 -maxdepth 1 | head
test -x node_modules/.bin/vite

اس تعمیر میں، پہلے چیک پر کوئی انسٹال شدہ پیکجز نہیں ملے۔ دوسرے نے تصدیق کی کہ وائٹ ایگزیکیوٹیبل غائب تھا۔ غائب بائنریز بھی ترقیاتی انحصار کو چھوڑنے کی وجہ سے ہوسکتی ہیں، لہذا کوئی تبدیلی کرنے سے پہلے ڈائریکٹری کو چیک کریں۔ NODE_ENV یا پیکیج مینی فیسٹ۔

اگر کامیابی سے انسٹال ہو جائے تو، آپ کو ڈائریکٹری کی فہرست میں پیکیج کا نام نظر آنا چاہیے۔ کہ test -x کمانڈ کچھ بھی نہیں پرنٹ کرتا ہے۔ اس کے فورا بعد، باہر نکلنے کی حیثیت کی جانچ پڑتال کی جاتی ہے.

echo $?

اگر وائٹ ایگزیکیوٹیبل غائب ہے تو متوقع نتائج یہ ہیں:

1

نتیجہ 0 اس کا مطلب یہ ہے کہ قابل عمل موجود ہے اور قابل عمل ہے۔

چوکی: ایک خالی انحصار ڈائرکٹری تنصیب کے مرحلے کی طرف اشارہ کرتی ہے۔ اگر آپ کے پاس دوسرے پیکیجز ہیں لیکن وائٹ غائب ہیں، تو یہ بھی یقینی بنائیں کہ انسٹالیشن کے دوران ڈیولپمنٹ انحصار کو چھوڑ دیا گیا ہے۔ یہ کمانڈز انحصار ڈائریکٹریز کو تبدیل کیے بغیر چیک کرتی ہیں۔

مرحلہ 2: تلاش کریں کہ لاک فائل پیکیج کو کہاں ڈاؤن لوڈ کرے گی۔

عام اشیاء میں شامل ہیں:

{
  "node_modules/example-package": {
    "version": "1.2.3",
    "resolved": "http://packages.internal.invalid/npm/example-package/-/example-package-1.2.3.tgz",
    "integrity": "sha512-"
  }
}

کہ .invalid مندرجہ بالا میزبان نام اصل اندرونی میزبان نام کی جگہ لے لیتا ہے۔ ڈھانچہ تاریخی لاک فائل سے میل کھاتا ہے۔

این پی ایم دستاویزات resolved یہ آپ کو دکھائے گا کہ پیکیج کہاں موصول ہوا تھا۔ رجسٹری پیکجز کے لیے، وہ قدر ٹربال URL ہو سکتی ہے۔ لہذا، بلڈ ایگزیکیوٹر میں تشکیل شدہ رجسٹری نے اس مسئلے کو حل نہیں کیا۔ لاک فائل پہلے ہی npm کو بتاتی ہے کہ ہر ٹربال کہاں سے حاصل کرنا ہے۔

ہم نے ہسٹری فائل سے متاثرہ آئٹمز کا حساب لگایا۔ 1,038 انحصاری اندراجات میں سے 528 نے داخلی میزبان ناموں کو پاس کیا۔ ہر ایک نے بیرونی تعمیراتی ماحول میں ایک غیر حل شدہ میزبان کی طرف اشارہ کیا۔

npm ڈیبگ آؤٹ پٹ پچھلی خرابی کو ظاہر کرتا ہے: میزبان نام کی غلطی پہلے ظاہر ہوئی ہے۔ Exit handler never called!. حکم اہم تھا۔ ایگزٹ ہینڈلر کے پیغام نے بتایا کہ این پی ایم کیسے باہر نکلا، اور ناکام ڈاؤن لوڈ نے وضاحت کی کہ انحصار کا درخت کیوں خالی تھا۔

ایک پیکیج کا نام تلاش کرنے کے بجائے، لاک فائل کو ڈیٹا کے لیے جانچا گیا۔ یہ چھوٹی سی اسکرپٹ تمام HTTP کو ایک ساتھ گروپ کرتی ہے۔ resolved میزبان نام کے لحاظ سے قدریں:

const fs = require('node:fs')
const lock = JSON.parse(fs.readFileSync('package-lock.json', 'utf8'))
const hosts = {}

for (const entry of Object.values(lock.packages ?? {})) {
  if (!entry.resolved?.startsWith('http')) continue
  const host = new URL(entry.resolved).host
  hosts[host] = (hosts[host] ?? 0) + 1
}

console.table(hosts)

اس انوینٹری کے مطابق، اس مسئلے نے صرف ایک ٹوٹا ہوا ٹربال نہیں بلکہ 528 اشیاء کو متاثر کیا۔ مرمت کی حدود بھی واضح کر دی گئیں۔ پیکیج لوکیشن میں ریکارڈ کیا گیا۔ resolved تبدیلیوں کی ضرورت تھی، لیکن ورژن اور سالمیت کی قدریں وہی رہیں۔ اگر آپ کی میزبان فہرست میں نجی رجسٹریاں شامل ہیں، تو یہاں رکیں اور ان پیکجوں کی شناخت کریں جنہیں وہ دوبارہ بنانے سے پہلے پیش کرتے ہیں۔

تاریخی انوینٹری اس قطار پر مشتمل ہے۔ جدول مثالوں میں میزبان کے متبادل نام استعمال کرتا ہے۔

ماسٹر تصدیق شدہ URL
packages.internal.invalid 528

میزبان کا نام اور نمبر لاک فائل پر منحصر ہے۔ یہ انوینٹری HTTP ٹربال کے مقامات کو شمار کرتی ہے، لہذا کل انحصار کی تعداد سے مختلف ہو سکتا ہے۔

چوکی: ناقابل رسائی میزبانوں کی شناخت کریں اور عوامی این پی ایم رجسٹریوں سے نکالے گئے پیکجوں کی جانچ کریں۔ متبادل سابقہ ​​منتخب کرنے سے پہلے، متاثرہ نمبر کو نوٹ کریں۔ صرف میزبان ناموں کی تعداد اس بات کا تعین نہیں کرتی ہے کہ آیا اس URL کو دوبارہ لکھنا محفوظ ہے۔

مرحلہ 3: صرف معلوم عوامی پیکیج URL کے سابقے دوبارہ لکھیں۔

لاک فائل کو دوبارہ بنانا رجسٹری کی مرمت اور انحصار کی تازہ کاریوں کا مرکب ہوسکتا ہے۔ پیکج کے ورژن اور سالمیت کی قدروں کو غیر تبدیل کرنے سے بحالی کا جائزہ لینا آسان ہو جاتا ہے۔

اس ایپلیکیشن سے متاثر ہونے والے پیکجز پبلک npm رجسٹری سے آتے ہیں۔ ڈویلپمنٹ پلیٹ فارم نے اس کا پراکسی کیا اور سالمیت کی اقدار کو محفوظ کیا۔ کنٹینر کی تنصیب سے پہلے تاریخی بحالی نے URL کے سابقہ ​​کو تبدیل کر دیا۔

اس مشق کے لیے، ہم درج ذیل کو محفوظ کرتے ہیں: rewrite-lockfile.cjs. صرف وہی چیز ہے جو بدل جاتی ہے۔ resolved منظور شدہ سابقوں کے ساتھ فیلڈز۔ فائل لکھنے سے پہلے، پرانے ہوسٹ کو انٹیگریٹی ویلیوز اور غیر متوقع راستوں کے لیے چیک کیا جاتا ہے۔

const fs = require('node:fs')

const oldPrefix = 'http://packages.internal.invalid/npm/'
const newPrefix = 'https://registry.npmjs.org/'
const oldHostname = new URL(oldPrefix).hostname
const filename="package-lock.json"
const lock = JSON.parse(fs.readFileSync(filename, 'utf8'))

if (!lock.packages || typeof lock.packages !== 'object') {
  throw new Error('Expected a lockfile with a packages object (version 2 or 3)')
}

let rewritten = 0
for (const entry of Object.values(lock.packages)) {
  if (typeof entry.resolved !== 'string') continue
  if (!entry.resolved.startsWith(oldPrefix)) continue
  if (!entry.integrity) throw new Error('An affected package has no integrity value')
  entry.resolved = newPrefix + entry.resolved.slice(oldPrefix.length)
  rewritten += 1
}

for (const entry of Object.values(lock.packages)) {
  if (typeof entry.resolved !== 'string') continue
  if (!entry.resolved.startsWith('http')) continue
  if (new URL(entry.resolved).hostname === oldHostname) {
    throw new Error('The old hostname remains under an unexpected URL prefix')
  }
}

fs.writeFileSync(filename, JSON.stringify(lock, null, 2) + 'n')
console.log(`Rewrote ${rewritten} resolved URLs`)

جب آپ انحصار کے مرحلے میں اسکرپٹ چلاتے ہیں، تو اس کا پیغام ان URLs کی تعداد سے مماثل ہونا چاہیے جو منظور شدہ سابقہ ​​استعمال کرتے ہیں۔ اس ٹیوٹوریل کی توثیق کرنے کے لیے یہاں ایک چھوٹا ٹیسٹ پروجیکٹ استعمال کیا گیا ہے:

Rewrote 40 resolved URLs

ٹیسٹ پروجیکٹ ماضی کی درخواست سے الگ ہے، جس میں 528 متاثرہ اشیاء تھیں۔ اپنی فائلوں کی اپنی انوینٹری کو تخمینہ کے طور پر استعمال کریں۔ پہلے سے بازیافت فائلوں کی تعداد 0 ہونے کی توقع ہے۔ اگر ناقابل بازیافت فائلیں 0 پیدا کرتی ہیں تو سابقہ ​​کو چیک کریں۔

اسکرپٹ یہ ثابت نہیں کرتا ہے کہ پیکیج عوامی ہے۔ براہ کرم الگ سے چیک کریں۔ پھر، npm کی سالمیت کی جانچ اس بات کی تصدیق کرتی ہے کہ ڈاؤن لوڈ کردہ بائٹس لاک فائل سے مماثل ہیں۔

مقامی انحصار اور کنفیگریشن فائلوں کو تعمیراتی تناظر میں استعمال کرتے ہوئے رکھیں: .dockerignore:

node_modules
dist
.git
.env*
.npmrc

یہ مثال ایک عوامی پیکیج کو انسٹال کرتی ہے۔ پرائیویٹ رجسٹریوں کو سیکیورٹی کی تعمیر کے دوران ان کے اپنے قابل رسائی اختتامی مقامات اور تصدیق کی ضرورت ہوتی ہے۔

ذیل میں پہلا بلاک اصل Dockerfile سے متاثر ہدایات دکھاتا ہے۔ دوسرا ایک مکمل ٹیوٹوریل تعمیر ہے۔ یہ نوڈ 24 اور ایک محفوظ تنصیب کا استعمال کرتا ہے، لہذا اپنی درخواست کے ساتھ مطابقت کی جانچ کریں۔

پچھلا: اصل انسٹالیشن اور بلڈ آرڈر

COPY package.json package-lock.json ./
RUN npm ci

COPY . .
RUN npm run build

اس کے بعد: URL کو دوبارہ لکھنا اور انحصار کی جانچ کرنا

اس بات کو یقینی بنانے کے لیے دو تعمیراتی مراحل استعمال کریں کہ ماخذ کی تبدیلیاں انحصار کی تنصیب کے مرحلے کو باطل نہیں کرتی ہیں۔

FROM node:24-slim AS dependencies
WORKDIR /app

COPY package.json package-lock.json rewrite-lockfile.cjs ./
RUN node rewrite-lockfile.cjs 
 && npm ci --include=dev 
 && test -x node_modules/.bin/vite

FROM node:24-slim AS build
WORKDIR /app

COPY . .
COPY --from=dependencies /app/node_modules ./node_modules
COPY --from=dependencies /app/package-lock.json ./package-lock.json
RUN npm run build

نظر ثانی شدہ ڈاکر فائل انسٹالیشن کے ہر حصے کو واضح کرتی ہے۔

  • URL کو دوبارہ لکھنا پہلے سے منظور شدہ عوامی پیکیج کے سابقوں کی جگہ لے لیتا ہے۔ npm ci پیکیج ڈاؤن لوڈ کریں۔

  • --include=dev واضح طور پر ترقیاتی انحصار کو انسٹال کرنے کا انتخاب کریں۔

  • اگر وائٹ انسٹالیشن کی وجہ سے غائب ہے تو وائٹ ایگزیکیوٹیبل چیک انحصار کے مرحلے کو روکتا ہے۔

  • ایک الگ انحصار مرحلہ ایپلی کیشن بنانے کے مرحلے کے دوران پیکجوں کو کاپی کرتا ہے اور ذریعہ کو مرتب کرنے سے پہلے انسٹال کرتا ہے۔

دوسرا مرحلہ درخواست کے ذریعہ کے بعد بازیافت شدہ لاک فائل کو کاپی کرتا ہے۔ دوسری صورت میں COPY . . اصل لاک فائل کو دوبارہ بلڈ امیج میں ڈالیں۔ کہ .dockerignore علاقے کو بھی روکیں۔ node_modules یقینی بنائیں کہ آپ پہلے مرحلے سے کسی بھی انحصار کو اوور رائٹ نہیں کرتے ہیں۔

--include=dev یہاں تک کہ اگر آپ کا تعمیراتی ماحول ترتیب دیا گیا ہے، وائٹ کو شامل کریں اگر یہ ترقیاتی انحصار ہے۔ NODE_ENV=production. یہ تصویر ایک تعمیراتی ماحول ہے، لہذا آپ کو ایک کمپائلر اور بلٹ ٹولز کی ضرورت ہوگی۔ نوڈ کا ایک معاون ورژن منتخب کریں جو آپ کے پروجیکٹ کے ساتھ مطابقت رکھتا ہو۔

ایک تاریخی لاک فائل کے موازنہ میں 528 تبدیل شدہ فیلڈز ملے، سبھی کے نام ہیں۔ resolved. پتہ چلتا ہے کہ 0 بدل گیا ہے۔ version یا integrity فیلڈ اور کوئی باقی اندرونی میزبان نام نہیں ہے۔ اوپر دی گئی مثال کی اسکرپٹ JSON فارمیٹ کو تبدیل کر سکتی ہے، لیکن اس سے خارجی فیلڈز کو بھی کوئی تبدیلی نہیں ہوتی۔

دوبارہ لکھنا صرف ہر ایک شناخت شدہ URL کو تبدیل کرتا ہے جو متاثر ہوتا ہے۔ پیکیج ورژن اور سالمیت کی قدریں ایک جیسی ہیں۔

تصویر 2۔ پورٹیبلٹی ریکوری انحصاری IDs کو محفوظ رکھتے ہوئے پیکیج کے مقامات کو تبدیل کرتی ہے۔

اگر وائٹ ابھی بھی غائب ہے تو قابل عمل چیک انحصاری قدم کو ناکام بنائے گا۔ ڈوکر ایپلی کیشن کی تعمیر تک پہنچنے کے بجائے اس مرحلے پر رک جاتا ہے۔

چوکی: اپنی انوینٹری میں دوبارہ لکھنے کی تعداد کو چیک کریں، اس بات کو یقینی بنائیں کہ پرانے قبول شدہ میزبان نام ختم ہو گئے ہیں، اور مرمت سے پہلے اور بعد میں ورژن اور سالمیت کی قدروں کا موازنہ کریں۔ انحصار کا مرحلہ دونوں کو مکمل کرنا چاہیے۔ npm ci --include=dev اور وائٹ ایگزیکیوٹیبل چیک کریں۔ مرحلہ 5 امیج بناتا ہے اور ایپلیکیشن آؤٹ پٹ کی تصدیق کرتا ہے۔

مرحلہ 4: تمام اسٹینڈ تنہا تنصیبات پر گارڈ کا اطلاق کریں۔

مسلسل انضمام کے کام اور کنٹینر امیج بنانے والوں نے الگ الگ تنصیبات چلائیں۔ ورک فلو لانچر میں ترمیم کرنے سے کچھ نہیں بدلا۔ npm ci ڈاکر فائل کے اندر۔ امیج بلڈز نے اصل ریپوزٹری فائلیں وصول کیں اور دوسرے ماحول میں اپنی انحصار کی پرتیں بنائیں۔

انحصار شدہ فائلوں کے انسٹالیشن ماحول میں داخل ہونے کے فورا بعد دوبارہ لکھنا ہوتا ہے۔ ڈوکر کی کیشے کے رہنما خطوط اکثر تبدیل کرنے والی سورس فائلوں کو کاپی کرنے سے پہلے انحصار کو انسٹال کرنے کی تجویز کرتے ہیں۔ مثال کے طور پر، انحصار کے مراحل کی اپنی حدود ہوتی ہیں: صرف ماخذ کو تبدیل کرنے سے درخواست کا مرحلہ دوبارہ تعمیر ہوتا ہے۔

ہر آزاد تنصیب سے پہلے ایک جیسے گارڈز لگائیں۔

  • مسلسل انضمام کی قسم چیک کی تنصیب

  • کنٹینر کی تعمیر انسٹال کریں۔

  • ملٹی اسٹیج ڈوکر فائل کے رن ٹائم اسٹیج کو انسٹال کرنا

ریپوزٹری لاک فائل کو CI ایگزیکیوٹر اور کنٹینر بلڈر میں الگ سے داخل کیا جاتا ہے۔ ہر ماحول npm ci چلانے سے پہلے URLs کو دوبارہ لکھتا اور تصدیق کرتا ہے۔

شکل 3. ورک فلو کی مرمت کنٹینر کی تعمیر کے اندر تنصیبات کی خود بخود مرمت نہیں کرتی ہے۔

اس ترتیب نے گمراہ کن ترامیم کو بھی روکا۔ چونکہ دونوں ملازمتوں نے الگ الگ تنصیبات میں ایک ہی لاک فائل کا استعمال کیا تھا، اس لیے امیج کی تعمیر ناکام ہوگئی، لیکن ٹائپ چیک پاس ہونے میں کامیاب رہا۔

مرحلہ 5: انحصار کے درخت اور اعتماد کی حدود کی تصدیق کریں۔

یہ مرمت محفوظ تھی کیونکہ متاثرہ اشیاء شفاف ترقیاتی پلیٹ فارم پراکسی کے پیچھے عوامی npm پیکجوں کی نمائندگی کرتی تھیں۔ سالمیت کی تار ایک جیسی رہی اور دوبارہ تعمیر نے پیکیج ورژن کو تبدیل نہیں کیا۔

ایک ہی متبادل پرائیویٹ پیکجز، پیچ شدہ پیکجز، یا ایک ہی پیکیج ورژن میں مختلف بائٹس فراہم کرنے والی رجسٹریوں کے لیے محفوظ نہیں ہے۔ پورٹ ایبل بلڈز کو اپنے پیکجز کو نجی، قابل رسائی رجسٹری میں برقرار رکھنا چاہیے اور اس رجسٹری کے لیے تصدیق کنفیگر کرنا چاہیے۔

اس پیٹرن کو کہیں اور لگانے سے پہلے میں کروں گا۔ resolved میزبان کا نام بتائیں اور عوامی اور نجی پیکجوں کو الگ کریں۔ اس کے بعد تبدیلی سے پہلے اور بعد میں پیکیج ورژن اور سالمیت کی اقدار کا موازنہ کرتا ہے۔ اگر کوئی غیر مجاز میزبان نام باقی رہے تو تعمیر ناکام ہو جائے گی۔

npm CLI مسئلہ ایک ہی چیز کو لاگ کرتا ہے۔ Exit handler never called! اندرونی رجسٹری سے پیکج ڈاؤن لوڈ کرنے کے بعد پیغام کا وقت ختم ہو گیا۔ پیغام خود پیکیج کے مقام کی شناخت نہیں کرتا ہے۔ اس معاملے میں، ٹربال URL اور ناکام ہوسٹ نام کو وجہ کے طور پر قائم کیا گیا تھا۔

تصویر بنائیں اور آؤٹ پٹ چیک کریں۔

docker build --progress=plain -t vite-install-check .
docker run --rm vite-install-check sh -c 
  'test -x node_modules/.bin/vite && test -s dist/index.html'

تعمیر کو گزرنا چاہئے۔ npm ciوائٹ ایگزیکیوٹیبل اسکین اور npm run build. آخری کمانڈ نتیجے میں آنے والی تصویر میں متوقع وائٹ آؤٹ پٹ کی تصدیق کرتی ہے۔ اگر آپ کا پروجیکٹ مختلف ڈائرکٹری استعمال کرتا ہے تو آؤٹ پٹ ریزولوشن کو ایڈجسٹ کریں۔ اس مثال میں تصویر درخواست کو مرتب کرتی ہے۔ اگر آپ کو پروڈکشن ویب سرور درکار ہے تو، ایک علیحدہ پروویژننگ مرحلہ منتخب کریں۔

ایک کامیاب کم سے کم مثال موجودہ ایپلی کیشن کے تمام انحصار کی توثیق نہیں کرتی ہے۔ جس پروجیکٹ کو آپ ریلیز کرنا چاہتے ہیں اس کے لیے وہی بلڈ چلائیں۔ اگر کوئی ٹول غائب ہے تو بلڈ ٹول کو تبدیل کرنے سے پہلے انسٹالیشن کے نتائج اور پچھلی خرابیوں کو چیک کریں۔

حوالہ جات

متعلقہ پوسٹس

اوپر تک سکرول کریں۔