პაკეტების მენეჯმენტი

ამ სტატიაში ვისწავლით როგორ ვმართოთ პაკეტები ჩვენს პროექტში, ამი როგორ დავაინსტალიროთ, განვაახლოთ და გამოვიყენოთ პაკეტები.

პროექტში პაკეტების დამატება

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

მარტივი მაგალითი იმ პაკეტისა, რომელიც ჩვენ პროექტს შეიძლება დასჭირდეს, არის კოდი, რომელიც გამოთვლის და გარდაქმნის დროს ადამიანისთვის გასაგებ ფორმატში. რა თქმა უნდა, ასეტი კოდის დაწერა თვითონაც შეგვიძლია, მაგრამ არის შანსი რომ ეს ამოცანა სხვამ უკვე გადაჭრა, ამიტომ არაა აუცილებელი ბორბლის ხელახლა გამოგონება. ამასთანავე, third-party პაკეტი, დიდი ალბათობით, გატესტილი იგნება სხვადასხვა სიტუაციებში, შესაბამისად ის უფრო მოქნილი იქნება სხვადასხვა კონტექსტებში თუ ბრაუზერების ვერსიებს შორის.

პროექტის dependency შეილება იყოს მთლიანი ჯავასკრიპტის ბიბლიოთეკა, ფრეიმვორკი - როგორიცაა Vue, Angular ან React - ერთი ბეწო დამხმარე კოდი, როგორიცაა თარიღის ტრანსფორმაციის ბიბლიოთეკა, ან კომანდ-ლაინ ხელსაწყო, როგორიცაა Prettier ან ESLint.

თანამედროვე ბილდის ხელსაწყოების გარეშე მსგავსი პაკეტები პროექტში შეიძლება ამრტივი <script>-ის ელემენტში შემოტანით, მაგრამ ხშირ შემთხვევაში დაგვჭირდება თანამედროვე ხელსაწყო, რომ პაკლეტები და ჩვენი კოდი ერთად შევკრათ და ვებზე გამოვაქვეყნოთ. შეკვრა (bundle) არის ტერმინი, რომელიც გამოიყენება ვებ სერვერზე არსებული ერთი ფაილის აღსაწერად, რომელიც შეიცავს ჩვენი აპლიკაციის მთლიან ჯავასკრიპტს - ჩვეულებრივ იგი მაქსიმალურად დაკომპრესებულია რათა შემცირდდეს ის დრო, რომელიც საჭიროა ჩვენი პროგრამის მომხმარებლის ბრაუზერში ჩასატვირთად.

გარდა ამისა, რას ვიზამთ მაშინ, როცა უკეთეს ხელსაწყოს ვიპოვნით და არსებულის ჩანაცვლებას მოვინდომებთ, ან ჩვენი პაკეტის ახალი ვერსია გამოვა და მისი განახლება დაგვჭირდება? თუ პროექტში თითო-ოროლა პაკეტი გვაქვს, ეს დიდი ამბავი არ არის, თუმცა დიდ პროექტებში სადაც ათობით dependency გვაქვს, ასეთი პროცედურები ძალიან რთულდება. სწორედ ამისთვის არის შექმნილი ისეთი პაკეტების მენეჯერი, როგორიცაა npm. იგი იზრუნველყოფს, რომ კოდი დაემატოს, წაიშალოს და განახლდეს სუფთად და ავტომატურად.

რა არის პაკეტების მენეჯერი?

პაკეტების მენეჯერი არის სისტემა, რომლითაც პროექტში პაკეტებს/dependency-ებს ვმართავთ. იგი გვაწვდის მეთოდებს, რომლითაც დავაინსტალირებთ ახალ პაკეტებს, ვმართავთ სად განთავსდებიან ისინი ფაილთა სისტემაში და გვთავაზობს ხელსაწყოებს, რომ გამოვაქვეყნოთ ჩვენი პაკეტებიც.

თეორიულად, შეიძლება პაკეტების მენეჯერი არც გამოვიყენოთ - ხელით ჩამოვწეროთ და ვმართოთ პროექტის dependency-ები, თუმცა პაკეტების მენეჯერი ამ პროცესს აჩქარებს და ამარტივებს. პაკეტების მენეჯერი რომ არ გვქონდეს, ჩვენით მოგვიწევდა:

• პაკეტებში სწორი ჯავასკრიპტის ფაილების მოძებნა.
• მათი შემოწმება რათა გამოვრიცხოთ ხარვეზები და საფრთხეები.
• მათი ჩამოწერა და პროექტში სწორ ადგილას მოთავსება.
• პაკეტების პროექტში შემოსატანი კოდის დაწერა (ჯავასკრიპტის მოდულებით).
• იმავე პროცედურების ჩატარება თვითონ პაკეტების dependency-ებზე, რომლებიც შეიძლება ათობით ან ასობით იყოს.
• ყველა ფაილის წაშლა, თუ პაკეტების მოშორება დაგვჭირდა.

ამასთანავე, პაკეტების მენეჯერები დუპლიკატ პაკეტებსაც მართავენ (რაც ფრონტ-ენდ დეველოპმენტში ხშირად საჭიროა).

npm-ის შემთხვევაში, პაკეტების საინსტალაციოდ გვაქვს ორი ადგილი. პაკეტები შეიძლება დავაინსტალიროთ გლობალურად, ან ლოკალურად - პროექტში. მიუხედავად იმისა, რომ გლობალურად ინსტალაციას ბევრი დადებითი მხარე შეიძლება ჰქონდეს, ლოკალურად ინსტალაციის პლიუსებს უფროპ მეტი უპირატესობა აქვს, მაგალითად კოდის პორტაბელურობა და ვერსიების ჩაკეტვა.

მაგალითად, თუ ჩვენი პროექტი დამოკიდებულია webpack-ზე და გააჩნია თავისი სპეციფიკური კონფიგურაცია, საჭიროა დავრწმუნდეთ, რომ თუ სხვა მოსწყობილობაზე დავაინსტალირეთ პროექტი ან საქმეს დიდი ხნის შემდეგ დავუბრუნდით, კონფიგურაცია მაინც იმუშავებს. თუ webpack-ის განსხვავებული ვერსია დავაინსტალირეთ, კონფიგურაციამ შეიძლება აღარ იმუშაოს. ამის თავიდან ასარიდებლად, პაკეტები დაინსტალირებულია პროექტში ლოკალურად.

თუ ლოკალური dependency-ების ეფექტურობის სანახავად, შეგიძლიათ ჩამოწეროთ რომელიმე პროექტი. თუ პროექტის თავისუფლად გაუშვებთ და ყველა მისი dependency სწორად იმუშავებს, ეს ლოკალური პაკეტების დამსახურებაა - იგი სხვადასხვა მოწყობილობებისთვისაა პორტატული.

პაკეტების რეგისტრი

იმისთვის, რომ პაკეტების მენეჯერმა იმუშაოს, მან უნდა იცოდეს საიდან დააინსტალიროს პაკეტები. რეგისტრი არის ცენტრალური ადგილი სადაც პაკეტებს აქვეყნებენ და, შესაბამისად, საიდანაც მათ აინსტალირებენ. npm, გარდა იმისა რომ პაკეტების მენეჯერია, არის ყველაზე გავრცელებული რეგისტრი ჯავასკრიპტის პაკეტებისთვის. ეგისტრი განთავსებულია npmjs.com-ზე.

რა თქმა უნდა, აქაც npm არ არის ერთადერთი ვარიანტი. არსებობს jsr რომელიც შედარებით ახალია და ნელ-ნელა პოპულარობას იძენს. ასევე შესაძლებელია საკუთარი რეგისტრების და npm-ის პროქსიების შექმნა Microsoft Azure-ისა და GitHub Registry Service-ის დახმარებით.

მნიშვნელოვანია, რომ ავარჩიოთ ჩვენთვის საუკეთესო რეგისტრი. პროექტთა უმეტესობა იყენებს (და კიდევ დიდი ხანი გამოიყენებს) npm-ს, ამიტომაც ამ სტატიის ფარგლებში ჩვენც იმავეს ვიზამთ.

პაკეტების ეკოსისტემის გამოყენება

ნაბიჯ-ნაბიჯ გავიაროთ ერთი მარტივი მაგალითი, რათა გავეცნოთ პაკეტების მენეჯერს, რეგისტრსა და კომანდ-ლაინ ბრძანებებს.

ამ მაგალითში გამოვიყენებთ Vite-ს ვებსაიტის შესაქმნელად.

Vite გვთავაზობს ინიციალიზაციის შაბლონებს, ყველა საჭირო კონფიგურაციებით, რათა დეველოპმენტი სწრაფად დავიწყოთ. ამ მაგალითში ჩვენით შევქმნით მინიმალურ სკაფოლდინგს.

აპლიკაციის, როგორც npm-ის პაკეტის მომზადება

პირველ რიგში, შევქმნათ ძირეული ფოლდერი, სადაც აპლიკაცია გვექნება. ამ ფოლდერს დავარქვათ npm-test (ან თქვენ რაც გაგიხარდებათ).

mkdir npm-test
cd npm-test

შემდეგ, ინიციალიზაცია გავუკეთოთ აპლიკაციას, როგორც npm-ის პაკეტს, რათა შევქმნათ კონფიგურაციის ფაილი - package.json - რომელიც საშუალებას მოგვცემს, შევინახოთ კონფიგურაციის დეტალები და, შესაბამისად, ზუსტად იგივე გარემო შევქმნათ შემდეგ ეტაპებზე, როცა, მაგალითად პროექტს გამოვაქვეყნებთ (როგორც ვებსაიტს), ან გავიტანთ პროექტს npm-ის რეგისტრში (თუმცა ეს უკანასკნელი ჩვენი პროექტისთვის შეუსაბამოა, რადგან აპლიკაციას ვაწყობთ და არა ბიბლიოთეკას).

npm-test ფოლდერში გავუშვათ შემდეგი ბრძანება:

npm init

პროგრამა რამდენიმე შეკითვას დაგვისვამს და შეგვიქმნის package.json ფაილს პასუხებიდან გამომდინარე. გაითვალისწინეთ, რომ ეს პასუხები რელევანტურია მხოლოდ გამოსაქვეყნებელი ბიბლიოთეკისთვის და არა აპლიკაციისთვის. შესაბამისად, ისინი ამ მაგალითში მნიშვნელოვანი არ არის. მიუხედავად ამისა, მაინც გავეცნოთ კონფიგურაციის ამ ველებს:

• name: აპლიკაციის იდენტიფიკატორი სახელი. უბრალოდ Return-ს თუ დავაჭერთ, იგი იქნება ძირეული ფოლდერის სახელი - npm-test.
• version: აპლიკაციის ვერსიის ნომერი. Return-ზე დაჭერით ავტომატურად გვექნება 1.0.0.
• description: აპლიკაციისა თუ ბიბლიოთეკის მოკლე აღწერა. ამას უბრალოდ გამოვტოვებთ და დავაჭერთ Return-ს.
• entry point: ეს იქნება ჯავასკრიპტის ფაილი, რომელიც გაესვება როცა სხვები ჩვენ პაკეტს დააიმპორტებენ. ჩვენ ესეც არ გვჭირდება, ამიტომ პირდაპირ დავაჭიროთ Return-ს.
• test command, git repository და keywords: თითოეული მათგანი დავტოვოთ ცარიელი და დავაჭიროთ Return-ს.
• author: პროექტის ავტორი. აქ შეგვიძლია ჩვენი სახელი და გვარი ჩავწეროთ და დავაჭიროთ Return-ს.
• license: ლიცენზია, რომლის ქვეშაც პაკეტს ვაქვეყნებთ. ჯერჯერობით, აქაც ავტომატური მნიშვნელობა დავტოვოთ Return-ზე დაჭერით.

საბოლოოდ, ყველა არჩეული პასუხის დასადასტურებლად, უკანასკნელად დავაჭიროთ Return-ს.

ახლა, npm-test ფოლდერში უნდა გამოჩნდეს package.json ფაილი, რომელიც დაახლოებით ასე უნდა გამოიყურებოდეს:

{
  "name": "npm-test",
  "version": "1.0.0",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC",
  "description": ""
}

ფაილში დავამატოთ კიდევ ორი სტრიქონი:

• "type": "module", რომელიც node-ს აიძულებს, რომ ყველა .js დაილს ინტერპრეტაცია გაუკეთოს, როგორც ES მოდულს, ძველი CommonJS მოდულის მაგივრად. ეს ზოგადად უკეთესი მიდგომაა.
• "private": "true", რომელიც უზრუნველყოფს, რომ შემთსვევით არ გამოვაქვეყნოთ ჩვენი პაკეტი npm-ის რეგისტრში. ამით განვსაზღვრავთ, რომ პროექტი არის კერძო.

დავამატოთ ეს სტრიქონები სადმე "name" ველის ქვეშ:

{
  "name": "npm-test"
  "type": "module",
  "private": true,
  // ... სხვა ველები
}

მაშასე, ჩვენი საწყისი კონფიგურაცია მზად არის.

Vite-ის ინსტალაცია

ახლა დავაინსტალიროთ ჩვენი ვებსაიტის ბილდის ხელსაწყო. ის პასუხს აგებს HTML, CSS-ისა და JavaScript-ის ფაილების თავმოყრაზე, ბრაუზერისთვის ოპტიმიზირებულ შეკვრაში.

npm install --save-dev vite

ბრძანების განხორციელების შემდეგ, თვალი შევავლოთ package.json-ს. npm-მა ახალი ველი დაგვიმატა:

"devDependencies": {
  "vite": "^7.0.0"
}

აი ეს არის npm-ის ზოგადი დანიშნულება - თუ მომავალში ჩვენ კოდს სხვაგან გადავიტანთ, მაგალითად სხვა მოწყობილობაზე, ჩვენ შეგვიძლია იგივენაირად მოვაწყოთ პროექტი ერთი ბრძანების გაშვებით: npm install. npm თავისით მოძებნის და დაგვიინსტალირებს პაკეტებს package.json-იდან გამომდინარე.

ერთი უარყოფითი მხარე არის ის, რომ Vite მხოლოდ ხელმისაწვდომია ჩვენი პროექტის ფოლდერში, npm-test-ში. ჩვენ მას სხვა ფოლდერში ვერ გავუშვებთ. მიუხედავად ამისა, დადებითი მხარეები მარტივად გადაწონის ამ პატარა პრობლემას.

ყურადღება მიაქციეთ, რომ ჩვენ Vite დავაინსტალირეთ, როგორც სადეველიპმენტო პაკეტი (dev dependency). ეს იშვიათად არის მნიშვნელოვანი აპლიკაციებისთვის, თუმცა ბიბლიოთეკის შემთხვევაში, როცა სხვები ჩვენ ბიბლიოთეკას (პაკეტს) დააინსტალირებენ, ისინი იმპლიციტურად Vite-ს არ ჩამოწერენ. ჩვეულებრივ, აპლიკაციებისთვის, ნებისმიერი პაკეტი რომელიც კოდშია დაიმპორტებული, არის ნამდვილი dependency, ხოლო ნებისმიერი პაკეტი, რომელიც დეველოპმენტისთვის გამოიყენება (მაგალითად კომანდ-ლაინ ხელსაწყოები) არის სადეველოპმენტო dependency, რომელიც ჩვენი აპლიკაციის თუ ბიბლიოთეკის მომხმარებლებს არ სჭირდებათ. ნამდვილი dependency-ების დაინსტალირება ხდება ინსტალაციის ბრძანების გაშვებით, --save-dev ფლაგის გარეშე.

vite-ის ინსტალაციის შემდეგ, არაერთ ახალ ფაილსაც შევამჩნევთ:

• node_modules: აქ ინახება dependency ფაილები, რომლებიც Vite-ის გასაშვებად არის საჭირო. npm-მა ისინი ჩვენმაგივრად ჩამოწერა.
• package-lock.json: ეს არის lockfile, რომელიც ინახავს საჭირო ინფორმაციას node_modules-ში არსებული ფაილების რეპლიკაციისთვის. ეს უზრუნველყოფს იმას, რომ თუ lockfile უცვლლი დარჩება, მოწყობილობებს შორის node_modules-ის შიგთავსი იქნება ერთი და იგივე.

ჩვენ ამ ფაილებზე არ ვდარდობთ, რადგან მათ მართავს npm-ი. თუ Git-ს ვიყენებთ, საჭიროა node_modules-ის დამატება .gitignore-ში, თუმცა, ზოგადად, package-lock.json უნდა დავიტოვოთ, რადგან იგი მოწყობილობებს შორის მოდულების მდგომარეობის სინქრონიზაციისთვისაა საჭირო.

აპლიკაციის მოწყობა

Vite-ში, index.html ფაილი არის ძალიან მნიშვნელოვანი. იგი აღნიშნავს აპლიკაციის საწყის წერტილს. Vite მას გამოიყენებს რომ მიაგნოს აპლიკაციის დასაბილდად საჭირო სხვა ფაილებს. შევქმნათ index.html ფაილი ჩვენი პროექტის ფოლდერში და მივცეთ შემდეგი შიგთავსი:

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>ჩემი სატესტო აპლიკაცია</title>
  </head>
  <body>
    <div id="app"></div>
    <script type="module" src="/src/main.js"></script>
  </body>
</html>

ყურადღება მიაქციეთ, რომ <script> ელემენტი ქმნის dependency-ს src/main.js ფაილზე, რომელიც აცხადებს აპლიკაციის ჯავასკრიპტის ლოგიკის ამოსავალ წერტილს. შევქმნათ src ფოლდერი და მასში განვათავსოთ main.js ფაილი, თუმცა დროებით ცარიელი დავტოვოთ.

გავერთოთ Vite-ით

ახლა ვცადოთ ჩვენი ახლად დაინსტალირებული Vite-ის გამოყენება! ტერმინალში გავუშვათ ბრძანება:

npx vite

უნდა დავინახოთ რაღაც ასეთი:

  VITE v7.0.0  ready in 47 ms

  ➜  Local:   http://localhost:5173/
  ➜  Network: use --host to expose
  ➜  press h + enter to show help

ჩვენ ახლა ვისარგებლოთ ჯავასკრიპტის სრულფასოვანი პაკეტების ეკოსისტემით! ჩვენ გავუშვით ლოკალური ვებსერვერი ამ მისამართზე http://localhost:5173/. აქ ჯერ ვერაფერს დავინახავთ (ბრაუზერის ტაბში სათაურის გარდა), თუმცა, თუ აპლიკაციაში ცვლილებებს შევიტანთ და შევინახავთ, Vite ავტომატურად ხელახლა დაბილდავს კოდს და დაარეფრეშებს სერვერს რათა შედეგი ბრაუზერში დაუყოვნებლივ გამოჩნდეს.

ჩვენ ამ სადეველოპმენტო სერვერის გათიშვა შეგვიძლია Ctrl + C ღილაკებზე დაჭერით. თუ გვინდა, რომ სერვერი გაშვებული დავტოვოთ, შეგვიძლია მეორე ტერმინალის ფანჯარა გავხსნათ, რომ სხვა ბრძანებები იქ გავუშვათ.

მოდით, საიტის კონტენტს მივხედოთ. სანიმუშოდ გვერდზე დავამატოთ დიაგრამა. ამისთვის გამოვიყენებთ plotly.js-ს, მონაცემების ვიზუალიზაციის ბიბლიოთეკას. მას დავაინსტალირებთ შემდეგი ბრძანებით:

npm install plotly.js-dist-min

ყურადღება მიაქციეთ, რომ პაკეტს ვაინსტალირებთ --save-dev ფლაგის გარეშე, რადგან, როგორც უკვე აღვნიშნეთ, ჩვენ ამ პაკეტს უშუალოდ კოდში გამოვიყენებთ, და არა როგორც მხოლოდ კომანდ-ლაინ ხელსაწყოს. ეს ბრძანება ახალ "dependencies" ველს დაამატებს package.json-ში.

"dependencies": {
  "plotly.js-dist-min": "^3.0.1"
}

გაითვალისწინეთ, რომ აქ პაკეტი წმინდად სადემონსტრაციოდ გამოვიყენეთ. რეალურ ვითარებაში, ჩვენ თავს რამდენიმე შეკითხვა უნდა დავუსვათ, როცა პაკეტს ვეძებთ და ვაინსტალირებთ

• ეს პაკეტი საერთოდ მჭირდება? იქნებ ჩემ პროექტში არსებული ფუნქციონალი ისედაც მიმაღწევინებს სასურველ მიზანს, ან თუნდაც შემიძლია იგივე გამოსავალი ჩემით მარტივად ავაწყო?
• კონკრეტულად რისი გაკეთება მინდა? რაც უფრო კარგად ვიცით რა მიზანს გვინდა მივაღწიოთ, მით უფრო შეგნებულად მოვძებნით საუკეთესო პაკეტს.
• ეს პაკეტი სანდო და კარგად შენახულია? ჩვენ დარწმუნებულები უნდა ვიყოთ, რომ პაკეტი განახლებულია და სხვები მას აქტიურად იყენებენ.

main.js ფაილში დავამატოთ შემდეგი კოდი:

import Plotly from "plotly.js-dist-min";

const root = document.getElementById("app");
Plotly.newPlot(
  root,
  [
    {
      x: [1, 2, 3, 4, 5],
      y: [1, 2, 4, 8, 16],
    },
  ],
  {
    margin: { t: 0 },
  },
);

ბრაუზერში დავუბრუნდეთ მისამართს http://localhost:5173 და ვნახოთ დიაგრამა. შეცვალეთ კოდში რიცხვები და ნახავთ, რომ ყველა შენახულ ცვლილებაზე აპლიკაცია განახლდება.

აპლიკაციის დაბილდვა

ჩვენი კოდი ჯერ მზად არ არის production-ისთვის. ბილდის სისტემათა უმეტესობას, მათ შორის Vite-საც, გააჩნია "დეველოპმენტის რეჟიმი" და "ფროდაქშენის რეჟიმი". განსხვავება არის ის, რომ გამოსადეგ ფუნქციონალთა დიდი ნაწილი, რომელსაც დეველოპმენტის დროს ვიყენებთ, არ გვჭირდება საბოლოო საიტზე, ამიტომ ისინი ფროდაქშენისთვის უნდა მოვაშოროთ, მაგალითად "hot module replacement", "live reloading" და "დაუკომპრესირებული და კომენტარებიანი კოდი". ასეთი ფუნქციონალი ძალიან გამოსადეგი და ფართოდ დამკვიდრებულია ვებ დეველოპმენტში, მაგრამ მხოლოდ დეველოპმენტის დროს და არა საბოლოო გამოქვეყნებულ შედეგში, ანუ ფროდაქშენზე. ფროდაქშენზე ეს ყველაფერი ჩვენ ვებსაიტს ტყუილად გატენის.

გავთიშოთ სადეველოპმენტო სერვერი Ctrl + C-თი.

ახლა შეუდგეთ ჩვენი ვითომ საიტის გამოქვეტნებას. ვიტი გვთავაზობს დამატებით build ბრძანებას, გამოქვეყნებისთვის ოპტიმიზირებული ფაილების დასაგენერირებლად.

გავუშვათ შემდეგი ბრძანება:

npx vite build

დავინახავთ მსგავს შედეგს:

vite v7.0.0 building for production...
✓ 7 modules transformed.
dist/index.html                    0.31 kB │ gzip:     0.23 kB
dist/assets/index-CGXfrYOM.js  4,621.25 kB │ gzip: 1,410.39 kB

(!) Some chunks are larger than 500 kB after minification. Consider:
- Using dynamic import() to code-split the application
- Use build.rollupOptions.output.manualChunks to improve chunking: https://rollupjs.org/configuration-options/#output-manualchunks
- Adjust chunk size limit for this warning via build.chunkSizeWarningLimit.
✓ built in 6.62s

Vite-მა შექმნა ფოლდერი სახელად dist. ეს ფოლდერი შეიცავს index.html-ს, რომელიც ძალიან ჰგავს ჩვენი პროექტის ძირეულ ფაილს, თიმცა შეიცავს <script>-ს, რომლის src ატრიბუტიც ახლა მიუთითებს ფაილზე assets ფოლდერში. assets ფოლდერი შეიცავს ტრანსფორიმებულ ჯავასკრიპტის ფაილს, რომელიც მინიფიცირებული და ოპტიმიზირებულია ფროდაქშენისთვის. ამ ფაილში არის დიაგრამის ბიბლიოთეკის ლოგიკაც, რომელიც ჩვენ src/main.js-ში უბრალო import-ის სინტაქსით გვაქვს შემოტანილი. ბრაუზერმა ხომ არ იცის import Plotly from "plotly.js-dist-min" რა ფაილზე მიუთითებს? Vite-მა იცის, რომ მოდულების ფოლდერიდან უნდა ამოიღოს საჭირო კოდი და ის ჩვენი ბილდის შედეგში შემოიტანოს.

პაკეტების მენეჯერის კლიენტის ზოგადი ფუნქციონალი

გაითვალისწინეთ რომ არსებობს სხვა პაკეტების მენეჯერებიც და კარგია, თუ, სულ მცირე, მათი არსებობის შესახებ მაინც გვეცოდინება.

არსებობს შემდეგი ცნობილი პაკეტების მენეჯერები:

• npm
• pnpm
• yarn

npm და pnpm ერთმანეთს ძალიან ჰგავს გამოყენების თვალსაზრისით. pnpm-ის მიზანი სწორედ npm-თან თავსებადობა არის. იგი სანაცვლოდ გვთავაზობს სცენებს მიღმა პაკეტების ჩამოწერისა და შენახვის განსხვავებულ მეთოდებს, რაც ამცირებს გამოყენებული მეხსიერების მოცულობას.

Yarn ხშირად განიხილება, როგორც npm-ზე უფრო სწრაფი პაკეტების მენეჯერი, როცა საქმე ინსტალაციას ეხება. ეს დეველოპერებისთვის მნიშვნელოვანია, რადგან საკმაოდ ბევრი დრო იხარჯება პაკეტების ინსტალაციის ლოდინში.

აქვე გასათვალისწინებელია, რომ npm-ისთვის არ არის პაკეტების ინსტალაცია npm-ის რეგისტრიდან. სამივე პაკეტის მენეჯერს შეუძლია package.json-ის წაკითხვა და პაკეტების ინსტალაცია ნებისმიერი სხვა პაკეტების რეგისტრიდან.

ახლა დროა განვიხილოთ ის ზოგადი ოპერაციები, რომლებსაც პაკეტების მენეჯერით ვახორციელებთ.

პროექტის ინიციალიზაცია

npm init

როგორც უკვე განვიხილეთ, ეს ბრძანება შეკითხვებს დაგვისვამს და შეგვადგენინებს package.json-ის ფაილს, რომელიც შეიცავს ინფორმაციას პროექტისა და მისთვის საჭირო პაკეტების შესახებ.

პაკეტების ინსტალაცია

npm install vite

ჩვენ ამ ბრძანების მაგალითიც უკვე განვიხილეთ, იგი დაგვიინსტალირებს სასურველ პაკეტს, ამ შემთხვევაში vite-ს, პროექტის ფოლდერში არსებულ node_modules ფოლდერში და, მასთან ერთად, vite-ისთვის საჭირო პაკეტებსაც.

ნაგულსხმევად, ბრძანება დააინსტალირებს პაკეტის უახლეს ვერსიას, თუმცა შეგვიძლია ჩვენთვის სასურველი ვერსიის მიწოდებაც. ეს შესაძლებელია პაკეტის სახელის შემდეგ ვერსიის მიწერით, მაგალითად vite@5 დააინსტალირებს უახლეს 5.x ვერსიას.

პაკეტების განახლება

npm update

ეს ბრძანება მოძებნის ჩვენი პროექტის პაკეტების განახლებებს, და ასეთის არსებობის შემთხხვევაში, მათ დააინსტალირებს იმ ვერსიის ფარგლებში, რაც მითითებულია პაკეტში.

ვერსიის ფარგლები პაკეტების ჩამონათვალშია მითითებული, მაგალითად, ჩვენი პროექტის package.json-ში არის "vite": "^7.0.0" - ამ ხემთხვევაში სიმბოლო ^ ნიშნავს ყველა minor და patch ვერსიებს, 7.0.0-დან 8.0.0-მდე (მაგალითად, 7.3.6, 7.2.2 და ა.შ).

ვერსიების ნუმერაცია ხდება სემანტიკური ვერსიის (semver)-ის მიხედვით. მარტივი სიტყვებით, ვერსიები აღირიცხება შემდეგნაირად: MAJOR.MINOR.PATCH, სადაც 2.5.1 ვერსია ნიშნავს 2 დიდ ცვლილებას (როცა წინა ვერსიებთან კონფლიქტში მოდის), 5 პატარა ცცლილებას (ახალი პატარა ფუნქციონალი) და 1 patch-ს (ხარვეზის გამოსწორება).

გასათვალისწინებელია, რომ npm update არ განაახლებს პაკეტს მიმდინარე ვერსიის ფარგლებს მიღმა. თუ ჩვენ ვერსიის ფარგლებს მიღმა განახლება გვინდა, მაშინ საჭიროა პაკეტის სპეციფიკური ვერსიით ხელახლა დაინსტალირება.

რა თქმა უნდა, ამით პაკეტების მენეჯერის ბრძანებები არ ამოიწურება. მიმართეთ თქვენი პაკეტების მენეჯერის დოკუმენტაციას დამატებითი დეტალებისთვის, ან გაუშვით პროგრამა --help ფლაგით:

npm --help

შევქმნათ ჩვენი ბრძანებები

პაკატების მენეჯერები საშუალებას გვაძლევს, შევქმნათ ჩვენი ბრძანებები, რომლებსაც კომანდ-ლაინზე გვუშვებთ. მაგალითად, აქამდე ჩვენ ვიყენებდით vite-ს npx-ით, რათა გაგვეშვა სადეველოპმენტო სერვერი. ჩვენ შეგვიძლია ასეთი ბრძანების შექმნა:

npm run dev

ეს ბრძანება გაუშვებდა ჩვენი "სადეველოპმენტო რეჟიმის" სკრიპტს. რეალურ პროექტებში ასეთ სკრიპტებს ხშირად ქმნიან, რადგან ერთმანეთისგან თვისებრივად განსხვავდება ლოკალური სადეველოპმენტო გარემო და ფროდაქშენის გარემო.

თუ ზემოთ ხსენებული ბრძანების გაშვება სცადეთ, მიიღებდით ერთგვარ ერორს, რომ "სკრიპტი სახელად dev არ არსებობს". ეს იმიტომ ხდება, რომ npm package.json-ში, scripts ველში ეძებს ბრძანებას, სახელად "dev", რომელიც ჯერჯერობით არ არსებობს. ამჟამად სკრიპტების ველი ასხე გამოიყურება:

"scripts": {
  "test": "echo \"Error: no test specified\" && exit 1",
},

როგორც ხედავთ, არსებობს მხოლოდ test ველი, რომელიც დიდად არაფერს აკეთებს. npm run test ბრძანება მუშაობს, თუმცა გვიბრუნებს მესიჯს: Error: no test specified. იგი უბრალდ წინასწარ გამზადებული შაბლონია. ამ ველის მნიშვნელობა მაინც სასარგებლო ინფორმაციას გვაწვდის, იგი უბრალო კომანდ-ლაინ ბრძანება, რომელიც იყენებს echo-ს:

echo "Error: no test specified" && exit 1,

მაშასადამე, სკრიპტებში შეგვიძლია შელის სკრიპტები/ბრძანებები დავწეროთ. npm ასეთ სკრიპტებს გაუშვებს ისეთ განსაკუთრებულ გარემოში, სადაც ჩვენი პროექტის ლოკალური პაკეტების კომანდ-ლაინ პროგრამებიც იქნება ხელმისაწვდომი, როგორიცაა ჩვენ მიერ დაინსტალირებული vite.

თუ vite-ის გაშვება გვინდა, როგორც ჩვენი სპეციალური npm ის ბრძანება, მას უბრალოდ ახალ სკრიპტად დავამატებთ:

"scripts": {
  "dev": "vite"
},

ახლა გვაქვს განსაკუთრებულ dev ბრძანება, რომელიც შეგვიძლია გავუშვათ ჩვენი პროექტის ფოლდერში:

npm run dev

სიმართლე ითქვას, npx vite უფრო მოკლე ბრძანებაა, და თითქოს დიდად სარგებელს არ გვაძლევს. მიუხედავად ამისა, npm-ის სკრიპტები არის აბსტრაქცია. იგი საშუალებას გვაძლევს, რომ მომავალში უფრო მეტი ოპერაციები ჩავამატოთ dev ბრძანებაში, მაგალითად გარემოს ცვლადების შექმნა, დროებითი ფაილების გენრაცია და ა.შ, ისე, რომ თვითონ ბრძანება ზედმეტად არ გადავტვირთოთ.

scripts-ში ბევრნაირი ბრძანება შეგვიძლია შემოვიტანოთ. მაგალითად, Vite ასეთ ბრძანებებს უწევს რეკომენდაციას:

"scripts": {
  "dev": "vite",
  "build": "vite build",
  "preview": "vite preview"
},

შეჯამება

ამ სტატიაში ვისწავლეთ პაკეტების მენეჯერის შესახებ: რა დანიშნულება აქვს პაკეტების მენეჯერს, პაკეტების შემოტანა და გაახლება, როგორ შეგვიძლია npm-ის ბრძანებების შექმნა და გაშვება.