JavaScript е лесно най-използваният език, когато става въпрос за разработване на уебсайтове и уеб приложения. Множеството ресурси са поразителни и още повече броят на наличните библиотеки.

Отначало тези библиотеки са малко и се поддържат лесно; обаче, скоро се задава ада и зависи по-зряло решение.

Въведете Node Package Manager (npm) - мениджър на пакети на JavaScript, който се използва най-вече заедно с Node.js , въпреки че може да се използва и самостоятелно. Той ви дава изключителен контрол върху зависимостите на вашия проект и предоставя чудесен начин да допринесете за света с отворен код.

Можете да започнете, като просто стартирате npm install и го инжектирате във вашия JavaScript файл.

Искате ли да инсталирате конкретна версия? Няма проблем. Изпълнение npm install @1.2.3.

Искате да инсталирате пакет глобално (като Mocha или Angular-CLI)? Просто добавете -g така: npm install -g angular-cli mocha.

Разбира се, повечето случаи на употреба спират при инсталиране в npm и няма нужда от нещо друго. Въпреки това, npm има много допълнителни функции, през които ще ви преведа, като подчертая онези, които считам за съществени, наистина полезни или просто страхотни.

CLI команди

CLI е мястото, където потребителите прекарват по-голямата част от времето си във взаимодействие с npm и неговият помощен интерфейс всъщност е полезен.

Помощта за заявки (npm help) извежда цял набор от опции и изпълнява npm help-search ви дава списък с резултати от търсенето директно от npm маркирането.

Ето основните команди, които се открояват.

• install: Тук се споменава поради огромната му необходимост при работа с npm. Използва се или за инсталиране на нов пакет локално или глобално (при добавяне -g) или за инсталиране на зависимости, изброени в package.json файл (повече за това по-късно).

  
  
  

• uninstall: Това също е от съществено значение. Използва се за прочистване на конкретен пакет от node_modules директория или локално, или глобално (при добавяне на -g).

• access: Това е площадката на администраторите на разрешения на потребителите на npm в контекста на npm-организации и обхванати (частни) пакети. Сериозно мощни неща. Използвано заедно с adduser, owner, team и т.н., дава фин контрол върху това кой има достъп до какво.

  
  
  

• bin: Къде на земята са инсталирани пакети? Изпълнете тази команда, за да видите абсолютния път на файла.

• cache: Ако започнете да инсталирате пакети от npm вляво, вдясно и от центъра, тази команда е доста полезна. Или го извикайте с ls подкоманда, за да видите списък с локално кеширани пакети или с clean подкомандата за изчистване на всички пакети, които са в кеша. Навремето, когато регистърът на npm все още беше малко нестабилен, това беше от съществено значение за връщане в стабилна среда или за нулиране на нещата, когато не сте настроили правилно разрешенията за npm.

• config: Ще влезем в различните опции за конфигуриране по-късно, но тази команда се занимава предимно с постоянни конфигурационни свойства в локалния или глобалния конфигурационен файл, като използва set, get или delete подкоманди.

  най-добрият език за кодиране за роботика

• dedupe или ddp: Когато работите по проект в продължение на дълъг период от време и инсталирате пакети направо от npm, тази команда ще извърви локалното дърво на пакета и ще се опита да опрости зависимостите.

• link: Когато разработвате свой собствен npm пакет, това ви позволява да създадете символна връзка към глобалния контекст, така че да може да бъде тествана, сякаш е инсталирана глобално от npm регистъра. Например, ако пишете инструмент за сглобяване във възел, който има CLI, инсталиран глобално, можете да изпълните тази команда и да тествате поведението на CLI, без да е необходимо първо да го разгръщате.

• ls: Използва се за визуализиране на зависимостите на пакетите и техните зависимости в дървовидна структура. Готино е да се види и е полезно и за сравнения с други проекти.

• outdated: Това се използва за оценка на текущото състояние на инсталираните зависимости и дали те са остарели или не. В проекти, където списъкът с коренови зависимости е със стотици редове, ръчната проверка на пакетите е почти невъзможна. Добавяне -g --depth=0 към тази команда ви позволява също да проверите вашите глобално инсталирани пакети.

• publish: Тази команда е от съществено значение при разработването на собствен пакет за npm. Прави точно както подсказва името; той публикува вашия пакет в npm регистъра.

• search: Използвайте това, за да търсите в системния регистър всички пакети, съдържащи текста, предоставен в третия аргумент.

• shrinkwrap: Накратко, тези команди ви позволяват да заключвате конкретни версии на зависимост в пакет по ред, така че спокойно полу ( семантична версия ) числото не нарушава производствения код.

• star: Наистина ли харесвате пакет, който използвате? Използвайте тази команда, за да покажете благодарността си директно от терминала, което след това се отразява на страницата на пакета в системния регистър на npm.

• update: Това обикновено следва outdated команда за актуализиране на всички остарели пакети.

• version: Това ви дава стенография за набиване на package.json version и направете git таг всичко в едно.

Имайте предвид, че повечето от тези команди могат да приемат подкоманди и / или конфигурации и този списък по никакъв начин не е дискусия за край на CLI.

npm-config

Конфигурацията е основна част от npm и има множество начини за конфигуриране на променливи за конфигуриране.

Конфигуриране чрез CLI и променливи на околната среда

Първо, конфигурацията може да бъде зададена чрез CLI от терминала.

Обикновено би изглеждало по следния начин: npm -- [].

Ако стойността не е посочена, по подразбиране опцията ще бъде зададена на true.

Да кажем например, че работите върху обхват (частен) npm пакет и решавате да го публикувате като обществен пакет.

Това става лесно, като добавите --access=public към вашия publish команда. Ако не посочим свойството да бъде публично, по подразбиране ще бъде ограничено (частно).

Конфигурацията, добавена към други команди като тази, не се запазва навсякъде, така че може да стане уморително да задавате набор от конфигурации чрез CLI.

В тези случаи може да е по-добре да зададете конфигурация, като използвате променливи на околната среда.

Всяка променлива на околната среда, зададена с npm_config_ префикс ще се използва за конфигуриране на npm.

хакната кредитна карта с баланс 2019

Например: export npm_config_registry=localhost:4321 ще зададе глобално опцията за конфигурация на системния регистър и когато се изпълни npm, той ще използва npm регистъра, намиращ се на localhost на порт 4321.

Конфигуриране чрез файла npmrc

Можете също да зададете опции за конфигуриране, като използвате специалния .npmrc файл, който може да бъде зададен на различни нива в зависимост от вашите изисквания:

• Проектно ниво: В основата на кода на проекта заедно с неговия package.json файл, обикновено path/to/project/.npmrc
• Потребителско ниво: Директорията, която конфигурира акаунт на конкретен потребител, обикновено ~/.npmrc
• Глобално ниво: Директорията, където npm търси глобални конфигурации, обикновено $PREFIX/etc/npmrc
• Вградено ниво: Бъдете внимателни. Тази конфигурация е не само глобална, но е и част от изходния код на npm и най-добрата практика препоръчва (всъщност изисква) да не променяме кода, който не носим отговорност за поддържането. Обикновено може да се намери на /path/to/npm/npmrc.

Настройки за конфигурация в .npmrc файл може да бъде модифициран и продължен с помощта на CLI чрез стартиране на команда в този формат: npm config set .

Например можете да стартирате npm config set access public за да направи конфигурацията за публикуване на обхванат (частен) пакет постоянно публична.

По подразбиране тази команда ще продължи локално конфигурацията (конфигурацията на ниво потребител, както е описано по-горе), но можете да добавите -g за да го запази глобално.

Когато постоянната конфигурация трябва да се случи на ниво проект или на вградено ниво, .npmrc файлът трябва да бъде модифициран с помощта на текстов редактор.

Конфигуриране чрез package.json

И накрая, конфигурацията може да бъде зададена от package.json файл. Това обаче се използва рядко (и трябва да се използва само ако изрично се изисква), тъй като ниво на проекта .npmrc файл е конвенционално предпочитаното място за задаване на конфигурация на пакета.

Забележителни настройки на конфигурацията

• access: Както беше обсъдено по-горе, той се използва за задаване на разрешения.

• always-auth: Важно е да се отбележи, че тази настройка по подразбиране е false. Когато е зададено на true, npm винаги ще изисква удостоверяване, когато се свързва с системния регистър.

• ca: По подразбиране за npm сертифициращия орган (CA). Той може да бъде променен на null, за да позволи достъп само до известни регистратори, или до конкретен CA сертификат, за да предостави достъп само до този конкретен. Тази настройка, заедно с cafile, cert и strict-ssl, се използват рядко, но говорят за аспекта на сигурността и надеждността на npm, позволявайки спокойствие да знаете, че пакетът, който инсталирате, идва от източника, който очаквате.

• color: Това по подразбиране е вярно, като ви дава почивка от стандартната мрачност на терминала, като оцветява stdout това е позволено от дескриптори на tty. Ако е зададено на false, терминалът остава скучен. Когато е зададено на always, винаги се извежда в цвят.

• depth: Тази настройка позволява гранулиран контрол върху това, което виждате с рекурсивни команди, като ls и outdated, като задава колко дълбоко са изпълнени. Стойност 0 ще оцени само първото ниво на зависимости, докато безкрайността (по подразбиране) ще доведе до оценка на всички нива на зависимости. Изключението от това правило е, когато се използва с outdated; в този случай безкрайността се интерпретира като 0, за да се осигури по-подходящ изход.

• dev: По подразбиране е зададено на false, но когато е зададено на true (когато се прави npm install) всички зависимости за разработка в package.json файлът ще бъде инсталиран заедно с нормалните зависимости.

• dry-run: Когато тази настройка е зададена на true, npm няма да прави промени в пакета ви, а вместо това ще ви каже какво би направил. Това може да бъде много полезно при изпълнение на определени команди, като dedupe или update.

• git-tag-version: По подразбиране е зададено на true. Тази настройка маркира версия в git при стартиране на npm version команда. Ако използвате npm като мениджър на пакети за голям проект, който има маркирани версии в git, това може да ви спести време и не забравяйте да актуализирате package.json файл за вас.

• loglevel: По подразбиране това е зададено на warn, което дава грешка и предупреждение при изпълнение на команди npm. Други настройки включват silent, което не осигурява изход; error, което регистрира само грешки в изхода; http, който само съобщава за грешки в http заявки; info, за нужен информативен изход); verbose, което регистрира почти всичко; и silly, което, както подсказва името, дава глупаво количество продукция и след това малко.

• production: Когато това е зададено на true, npm действа съответно и изпълнява всички команди в производствен режим. Това означава, че няма да бъдат инсталирани зависимости за разработка или по избор, нито ще бъдат изпълнени някакви задачи, свързани с разработката.

• rollback: Когато е зададено на true, всички неуспешни инсталации се премахват. Това е полезно, когато инсталирането на зависимости се провали. В зависимост от нивото на регистриране, трябва да можете да видите какви инсталации са се провалили, да ги отбележите и да стартирате npm install команда с опция за връщане, зададена на true. След това с вашите бележки и инсталация на сухо изпълнение (както е описано по-горе), можете след това да отстраните грешката в проблема.

• save : When installing a package directly from the registry, you can append –save to the command which will add the installed package to the dependencies option in the package.json file. For example, npm install lodash` ще добави lodash към вашите зависимости.

• save-dev: Подобно на опцията за запазване на конфигурацията, добавете --save-dev при инсталиране на пакет и след това той ще бъде добавен към опцията devDependencies в package.json файл.

• save-optional: Подобно на опцията за запазване на конфигурацията, добавете --save-optional при инсталиране на пакет и той ще бъде добавен към опцията optionalDependencies в package.json файл.

• save-exact: При инсталиране на пакети, save, save-dev и save-optional опции променят package.json файл, като вмъкнете инсталирания пакет в съответното му свойство с оператор за полудиапазон. При извикване на настройката за конфигурация „точно съхранение“ със стойност true, във връзка с една от споменатите настройки по-горе, се използва определен номер на версията, като се игнорира диапазона на semver.

• save-prefix: Това задава оператора на semver range, когато се използва save, save-dev или save-optional. По подразбиране е ^, което позволява да се извършват малки надстройки на пакети при инсталиране. Това може да бъде зададено на всеки валиден оператор с предварително зададен диапазон на semver.

• tag-version-prefix: Конвенционалният по подразбиране е v, указващ какво се добавя към версията на git тагове при изпълнение npm version

Актуализиране на npm Използване на npm

Можете също да използвате npm, за да се актуализира.

Просто стартирайте npm install -g [email protected] и npm ще бъде актуализиран до най-новата стабилна версия. Важно е да се отбележи, че всяка версия на Node.js се доставя с конкретна версия на npm и според моя опит не бива да се забърквате твърде много с това сдвояване.

В края на деня моята препоръка е да се придържате към сдвояването, както е предвидено.

Когато използвате npm като самостоятелен инструмент, уверете се, че разбирате последиците от използването на която и да е версия, която изберете. Има чудесен инструмент за управление на различни версии на Node.js (и от своя страна npm версии) в една и съща система, наречена nvm .

Файлът package.json

package.json файл е решаващият елемент, който свързва всичко заедно.

Това е изискване за публикуване на пакет в npm регистъра и именно там оживява частта за управление на зависимостите.

Той има две задължителни полета, а именно „име“ и „версия“ и заедно тези свойства трябва да бъдат уникален идентификатор.

Полето за име трябва да се придържа към определени правила, както са определени от npm документация за именуване , а полето за версия е предмет на спецификации на semver .

Освен това можете да имате списък с зависимости, дълги на миля, и да дефинирате конкретна версия, която да се използва за всяка от тях, като използвате версиите на semver и операторите на диапазона. Ето списък на други забележителни свойства.

„Главен“

“Main” определя точката за влизане във вашето приложение, която по подразбиране е index.js. В зависимост от конвенцията или вашата рамка може да е app.js или main.js. Можете, разбира се, да го направите каквото поискате.

„Скриптове“

Това е подценен имот.

Първо, той може да се използва за извършване на нещата при предварително публикуване.

Второ, осигурява място, където можете да създадете псевдоним на масив от често използвани команди, вариращи от задачи за изграждане (дефинирани в gulp или grunt), задействащи инсталирането на други зависимости (с нещо като bower), стартиране на сървър за разработка с webpack или изпълнение на набор от команди bash.

„Зависимости“

Това свойство е списък на пакетите, необходими на вашето приложение, заедно със съвместимия номер на semver. Това е забележително свойство, защото може да бъде модифицирано от терминала, когато инсталирате локални пакети.

Това става чрез добавяне на --save (или стенографията -S) в края на npm install команда.

Когато направите това, новоинсталираният (ите) пакет (и) се добавя към списъка на зависимостите във вашия package.json файл.

c и c++ програмиране

По същия начин зависимост също може да бъде премахната чрез добавяне на --save при стартиране на npm uninstall команда.

Важно е да сте наясно с моделите на версиите на semver за всяка от зависимостите и какво означават те.

Ако правилото на semver е твърде строго, вие губите от нови функции и подобрения, докато ако правилото на semver е твърде спокойно, по линията може да бъде инсталирана разчупваща версия на пакет.

Инсталирането на счупен пакет може да се окаже доста трудно за разрешаване, особено когато се използва умалената версия на пакета.

медийна заявка за всички мобилни устройства

“DevDependencies”

Отделно от свойството зависимости, свойството “devDependencies” ви позволява да дефинирате зависимости, които се използват само по време на фазата на разработка и не са необходими за производствената компилация (като ESLint, grunt-contrib пакети и Protractor). Точно както при зависимостите, това свойство може да бъде модифицирано от терминала чрез добавяне на --save-dev (или стенографията -D) до края на npm install команда или npm uninstall команда. Същото внимание се отнася и за версионирането, както е споменато под зависимости.

'Am'

Тук можете да посочите изпълнимия файл (и) на вашия пакет, като пътя към помощната програма на CLI. Това свойство казва на npm да създава локални или глобални символни връзки към вашите изпълними файлове, когато вашият пакет е инсталиран.

„Конфиг“

Както беше обсъдено по-рано, тук дефинирате настройките на конфигурацията чрез вашия package.json файл.

„Частен“

Когато е зададено на true, npm ще откаже да публикува пакета.

Това не трябва да се бърка с настройката за конфигурация на достъпа.

Това е удобна настройка, когато имате проект, който използва npm заедно със своите package.json но не е предвидено да бъде публикувано в npm регистъра, нито в обхват, нито публично.

Ако намерението ви се промени, просто променете настройката на false и ще можете да публикувате пакета си.

Персонализирани свойства

package.json файлът също така приема персонализирани свойства, стига името да не е вече дефинирано или запазено.

Разработване на ваш собствен npm пакет

Екосистемата npm е пълна с пакети, написани от хиляди различни разработчици по целия свят. Всеки решава някакъв проблем, като осигурява абстракция или представя изпълнение на нещо.

Шансовете са, че в даден момент и вие ще искате да разработите свой собствен пакет за споделяне.

Първо, трябва да създадете package.json файл с минимално необходимите свойства на „име“ и „версия“, а след това „основното“ свойство, за да се посочи входната точка, например index.js.

Напишете кода си в този файл index.js, влезте с вашия потребителски акаунт в npm или създайте нов потребител от терминала и сте готови да го публикувате в npm регистъра.

Пакетите могат да бъдат публични или частни.

Публичните пакети се публикуват безплатно и са достъпни за използване от всички.

Частни пакети, наречени обхванати пакети, могат да бъдат публикувани само ако сте платили потребител на частни модули и те могат да бъдат идентифицирани чрез отделния @username/ което се добавя към името на пакета.

Обхванатите пакети също могат да бъдат публикувани публично, като се обадите на publish команда с --access=public.

Освен това, ако отделите още малко време за разширяване и подобряване на кодовата база на вашия пакет и е време да бъде публикувана нова версия, просто променяте версията (според правилата и конвенциите на semver) на пакета в package.json файл и тип npm publish.

Можете също така да използвате интерфейса на командния ред и да извикате npm version , където update_type е patch, minor или major, както е описано от semver, и това автоматично увеличава номер на версията в package.json файл.

npm Организации

Отново, npm документация защото това е отлично и би било безполезно просто да се повтарят думите им.

Това, което може да се каже за организациите в контекста на npm, е, че те са изключително фини и когато се управляват правилно, големи екипи и лица, работещи върху обхват или публични пакети под едно име, могат да бъдат много добре управлявани и ограничавани.

Въпреки че е сложно да се овладее, това е много полезно.

Мощността на npm

В крайна сметка документацията, която npm предоставя, е обширна и трябва да се консултира за конкретни подробности, но тази статия предоставя полезен преглед както на основната, така и на по-усъвършенстваната, включена функционалност, предавайки страхотността на npm.

Както при всички неща, съществуват силни мнения и могат да се намерят много грешки. Но ако никога не сте опитвали npm (или възел, по този въпрос), потопете се и го проучете сами. Шансовете са, че ще ви хареса повече, отколкото си мислите.

За още интересни статии за npm, помислете за четене Използване на Scala.js с npm и Browserify .