Yarn: A Quick, Re­li­able and Safe Way to Share Code

Yarn is a col­lab­o­ra­tion be­tween Face­book, Ex­po­nent, Google and Tilde. It is a pack­age man­ager which aims at more re­li­able and se­cure in­stalls. It man­ages de­pen­den­cies con­sis­tently across ma­chines and also in a se­cure off­line en­vi­ron­ment.

OpenSource For You - - Contents -

Ear­lier, devel­op­ers typ­i­cally looked for the pack­age (JS, CSS) on the In­ter­net, down­loaded the zipped ver­sion, ex­tracted it and linked it to the Web page. But the first four steps were very time con­sum­ing. The more de­pen­den­cies that were re­quired, the more time devel­op­ers had to in­vest in re­peat­ing the same steps. More­over, all these de­pen­den­cies had to up­load in a ver­sion con­trol sys­tem, so that other devel­op­ers could re­use the same de­pen­den­cies in their projects.

To solve the prob­lem of manag­ing de­pen­den­cies, Bower en­tered the JavaScript world. This helped devel­op­ers to man­age de­pen­den­cies and share code, through the cen­tral reg­istry, with other devel­op­ers from around the world. But Bower had some short­com­ings which were re­solved by npm, which is the de­fault pack­age man­ager for Node.js. npm is good but it also has some short­com­ings that have now been re­solved by Yarn.

Yarn

Yarn is a pack­age man­ager for your code. It al­lows you to use and share code with other devel­op­ers from around the world through a cen­tral reg­istry and in other ways.

Yarn does this quickly, se­curely, and re­li­ably so you don’t ever have to worry. Yarn is fast, re­li­able and of­fers se­cure de­pen­dency man­age­ment.

Code is shared through some­thing called a pack­age/ mod­ule. A pack­age con­tains all the code be­ing shared as well as a pack­age.json file, which de­scribes the pack­age and de­pen­den­cies.

Shown below is a sam­ple for­mat of pack­age.json:

{ “name”: “yarn­test”, “ver­sion”: “1.0.0”,

“de­scrip­tion”: “”,

“main”: “in­dex.js”,

“scripts”: {

“test”: “echo \”Er­ror: no test spec­i­fied\” && exit 1” },

“de­pen­den­cies”: {

“se­ri­al­port”: “^4.0.0”

},

“au­thor”: “”,

“li­cense”: “ISC”

}

Why Yarn?

npm is good, but it also has some short­com­ings. Here is a list of some of them.

Nested de­pen­den­cies: npm ver­sion 2 nests de­pen­den­cies, which leads to du­pli­cates. For users of Win­dows, file paths may get long, which causes prob­lems with Win­dows when try­ing to delete them. To fix this prob­lem, you should use npm ver­sion 3.

Queued in­stall: It in­stalls each de­pen­dency one af­ter the other, which may take up a lot of time.

Sin­gle reg­istry: If a pack­age is not on the npm reg­istry, then for­get about down­load­ing it through npm.

No off­line in­stal­la­tion: Ev­ery time you have to down­load de­pen­den­cies from the npm reg­istry, a work­ing In­ter­net con­nec­tion is re­quired, which takes up a lot of time and consumes more band­width.

Yarn over­comes most of the short­com­ings of npm and pro­vides ad­di­tional power to man­age de­pen­den­cies. Here are the pow­er­ful fea­tures that Yarn of­fers.

Ul­tra-fast: It caches ev­ery pack­age it down­loads, so it never needs to down­load it again. It also par­al­lelises op­er­a­tions to max­imise re­source util­i­sa­tion; so in­stall times are faster than ever.

Off­line mode: If you’ve in­stalled a pack­age be­fore, you can in­stall it again with­out any In­ter­net con­nec­tion. Ex­tremely se­cure: Yarn uses check­sums to ver­ify the in­tegrity of ev­ery in­stalled pack­age be­fore its code is ex­e­cuted.

Su­per re­li­able: Us­ing a de­tailed, but con­cise, lock­file for­mat, and a de­ter­min­is­tic al­go­rithm for in­stalls, Yarn is able to guar­an­tee that an in­stall that worked on one sys­tem will work ex­actly the same way on any other sys­tem. Same pack­ages: You can in­stall any pack­age from npm and keep your pack­age work­flow the same.

Net­work re­silience: A sin­gle re­quest fail­ing will not cause an in­stall to fail. Re­quests are re­tried upon fail­ure. Flat mode: You can re­solve mis­matched ver­sions of de­pen­den­cies to a sin­gle ver­sion to avoid creat­ing du­pli­cates.

Yarn in­stal­la­tion

Be­fore us­ing Yarn, you’ll first need to in­stall it on your sys­tem. There is an in­creas­ing num­ber of ways to in­stall Yarn. But in this ar­ti­cle, I will cover only some of the op­tions.

1. In­stal­la­tion on Win­dows: This is done through the in­staller .msi file. Down­load it us­ing the link https://yarnpkg.com/ lat­est.msi

In­stall via Choco­latey (pack­age man­ager for Win­dows):

choco in­stall yarn In­stall via Scoop (com­mand-line in­staller for Win­dows): scoop in­stall yarn

2. In­stal­la­tion on Cen­tos, Fe­dora and RHEL Linux: In­stall it via the RPM pack­age repos­i­tory.

Step 1: sudo wget https://dl.yarnpkg.com/rpm/yarn.repo -O /etc/yum. re­pos.d/yarn.repo Step 2: sudo yum in­stall yarn

3. In­stal­la­tion on MacOS: In­stall Yarn through the Home­brew pack­age man­ager. This will also in­stall Node.js if it is not al­ready in­stalled.

brew in­stall yarn

Once Yarn is in­stalled, then by us­ing the com­mand given below, we can check what ver­sion it is: yarn --ver­sion

As of now, Yarn’s cur­rent sta­ble ver­sion is v0.27.5 and the lat­est un­sta­ble ver­sion is v.28.4 (Nightly Build – this re­lease may have bugs).

In­stalling project de­pen­den­cies

Here is a list of pos­si­ble Yarn com­mands that help us to add and in­stall project de­pen­den­cies.

1. yarn add: This com­mand in­stalls a pack­age and any pack­ages that it de­pends on. It in­stalls the de­pen­den­cies in the lo­cal node_­mod­ules di­rec­tory and also an en­try in the pack­age. json and yarn.lock files. So mem­bers of a team work­ing on the same project can get the same mod­ules in­stalled on their ma­chines by ex­e­cut­ing the yarn or yarn in­stall com­mands. 2. yarn in­stall: This is used to in­stall all de­pen­den­cies for a project listed within pack­age.json in the node_­mod­ules folder. It is most com­monly used when you have just checked out code for a project, or when an­other de­vel­oper on the project has added a new de­pen­dency that you need to pick up.

Some yarn add com­mands

yarn add <pack­age …> [--ex­act/-E]: Us­ing –ex­act or -E in­stalls the ex­act ver­sion of the pack­age. The de­fault is to use the most re­cent re­lease with the same ma­jor ver­sion.

yarn add <pack­age …> [--tilde/-T]: Us­ing –tilde or

-T in­stalls the most re­cent re­lease of the pack­ages that have the same mi­nor ver­sion. The de­fault is to use the most re­cent re­lease with the same ma­jor ver­sion. For ex­am­ple, yarn add de­bug@1.2.3 –tilde would ac­cept 1.2.9 but not 1.3.0. yarn add pack­age-name@tag: This com­mand is used to in­stall a pack­age of a spec­i­fied tag, e.g., beta, next or lat­est. yarn add <pack­age…> [--dev/-D]: Us­ing –dev or -D will in­stall one or more pack­ages in de­vDepen­den­cies in pack­age.json.

By de­fault, all these pack­ages get in­stalled from the npm reg­istry, but we can spec­ify a lo­cal folder path, URL, gzip tar­ball lo­cal file path, Git repos­i­tory URL, etc. A few ex­am­ples are given below. yarn add pack­age-name: In­stalls the pack­age from the npm reg­istry un­less we spec­ify an­other one in pack­age.json. yarn add <file:/lo­cal/lo­cal/folder>: In­stalls a pack­age that is on your lo­cal file sys­tem. This is use­ful to test out other pack­ages of yours that haven’t been pub­lished to the pub­lic/ pri­vate reg­istry yet. yarn add <file:/lo­cal/foder/tar­ball.tgz>: In­stalls a pack­age from a gzipped tar­ball, which could be used to share a pack­age be­fore pub­lish­ing it. yarn add <git re­mote url>: In­stalls a pack­age from a re­mote Git repos­i­tory. yarn add <git re­mote url>#<branch/com­mit/tag>: In­stalls a pack­age from a re­mote Git repos­i­tory at a spe­cific Git branch, Git com­mit or Git tag. yarn add <https://my­project.org/pack­age.tgz>: In­stalls a pack­age from a re­mote gzipped tar­ball.

In case you are us­ing npm, you would use –save or --save-dev. In Yarn, these have been re­placed by yarn add and yarn add –dev.

Some yarn in­stall com­mands

yarn in­stall –check­files: Ver­i­fies that files al­ready in­stalled in node_­mod­ules are not re­moved. yarn in­stall –force: Re-fetches all the pack­ages, even ones that were pre­vi­ously in­stalled. yarn in­stall –ig­nore­scripts: Does not ex­e­cute any scripts de­fined in the project pack­age.json and its de­pen­den­cies. yarn in­stall –mod­ules­folder <path>: By de­fault, pack­ages get in­stalled in the project node_­mod­ules di­rec­tory. With this com­mand, you can spec­ify a dif­fer­ent path to in­stall all de­pen­den­cies. yarn in­stall –no­lock­file: By de­fault, for ev­ery in­stal­la­tion, Yarn makes an en­try in the yarn.lock file. This com­mand in­structs Yarn to nei­ther read nor gen­er­ate a yarn.lock lock­file. yarn in­stall –pro­duc­tion[true|false]: Yarn will not in­stall any pack­age listed in de­vDepen­den­cies if the NODE_ENV en­vi­ron­ment vari­able is set to pro­duc­tion. Use this flag to in­struct Yarn to ig­nore NODE_ENV, and to take its pro­duc­tion-or-not sta­tus in­stead. yarn in­stall –off­line: Runs yarn in­stall in off­line mode.

Manag­ing de­pen­den­cies

Up­grad­ing or delet­ing pack­ages will au­to­mat­i­cally up­date pack­age.json and yarn.lock files. Other devel­op­ers work­ing on the project can run yarn in­stall to sync their own node_ mod­ules di­rec­to­ries with the up­dated set of de­pen­den­cies.

When we re­move a pack­age, it gets re­moved from prod, dev de­pen­den­cies.

yarn re­move [pack­age-name] ex: yarn re­move mon­goose

Pack­ages can also be up­graded to the lat­est or a lower ver­sion.

yarn up­grade [pack­age] yarn up­grade [pack­age]@[ver­sion] yarn up­grade [pack­age]@[tag]

Other use­ful Yarn com­mands

Yarn pro­vides rich sets of com­mands, but I will ex­plain only some of them.

Af­ter in­stalling Node.js and Yarn, we can start us­ing the Yarn com­mands to man­age de­pen­den­cies in our projects.

yarn init: This is the first com­mand we should run to cre­ate the pack­age.json file, which is used to man­age in­for­ma­tion like the project’s name, ver­sion or li­cence in­for­ma­tion, as well as the au­thor’s and con­trib­u­tors’ names – ba­si­cally, the de­tails of the most im­por­tant project de­pen­den­cies. This com­mand walks us through an in­ter­ac­tive ses­sion to cre­ate a pack­age.json file. yarn con­fig com­mands: Here is a list of a few of these. yarn con­fig list: Dis­plays the cur­rent con­fig­u­ra­tion. yarn con­fig set <key> <value> [­g| ­­global]: Sets the con­fig key to a cer­tain value. yarn con­fig get <key>: Echoes the value for a given key to std­out. yarn con­fig delete <key>: Deletes a given key from the con­fig. yarn cache com­mands: These list, clean and change the cache di­rec­tory. yarn cache ls: Yarn stores ev­ery pack­age in a global cache in your user di­rec­tory on the file sys­tem. This com­mand will print out ev­ery cached pack­age. yarn cache dir: This com­mand will print out the path where Yarn’s global cache is cur­rently stored. yarn cache clean: This will clear the global cache. It will be pop­u­lated again the next time yarn or yarn in­stall is

run. Ad­di­tion­ally, we can spec­ify the name of the pack­age we want to clean. yarn con­fig set cache­folder <path>: Sets cachefolder con­fig value to con­fig­ure the cache di­rec­tory. yarn clean: This com­mand frees up space by re­mov­ing un­nec­es­sary files and fold­ers from pack­age de­pen­den­cies. It is use­ful in an en­vi­ron­ment where pack­ages are checked into the ver­sion con­trol di­rectly.

On com­mand ex­e­cu­tion, Yarn will cre­ate a .yarn­clean file that should be added to ver­sion con­trol. Clean­ing is then au­to­mat­i­cally done as part of yarn in­stall (or sim­ply yarn) and yarn add.

Note: As a best prac­tice, it is rec­om­mended that you do not use this com­mand. This com­mand uses a heuris­tic to iden­tify files that may not be needed from a dis­trib­uted pack­age and may not be en­tirely safe. This com­mand is rec­om­mended only if you ex­pe­ri­ence is­sues with the num­ber of files that are in­stalled as part of node_­mod­ules.

yarn info <pack­age> [field]: This com­mand will fetch in­for­ma­tion about a pack­age and re­turn it in a tree for­mat. The pack­age need not have been in­stalled lo­cally.

Ex­am­ple: yarn info ex­press or yarn info ex­press ex­press@1.15.0.

Note that, by de­fault, yarn info will not re­turn the readme field (since it is of­ten very long). To ex­plic­itly re­quest that field, use yarn info re­act readme.

Yarn com­mands for manag­ing pack­age own­ers: Devel­op­ers can write their own pack­age and pub­lish it either in a pri­vate or pub­lic reg­istry. A pack­age ‘owner’ in the reg­istry is a user who has ac­cess to make changes to a pack­age. A sin­gle pack­age can have as many own­ers as you want.

Own­ers have per­mis­sion to do the fol­low­ing tasks:

1. Pub­lish new ver­sions of the pack­age

2. Add or re­move other own­ers of the pack­age

3. Change the meta­data for a pack­age

The fol­low­ing ta­ble lists a few yarn owner com­mands and their ap­pli­ca­tions.

Com­mands for pub­lish­ing a pack­age to the npm reg­istry: Once a pack­age is pub­lished, you can never mod­ify that spe­cific ver­sion, so take care be­fore pub­lish­ing it. The fol­low­ing ta­ble lists a few yarn pub­lish com­mands and their ap­pli­ca­tions.

Com­mand for run­ning a de­fined pack­age script in pack­age.json: De­fine a scripts ob­jects in your pack­age.json file like the one I have de­fined in the code given below: “name”: “my-pack­age-name”, “scripts”: {

“build”: “ba­bel­src-dlib”, “test”: “test-code”

Here, ex­e­cut­ing the com­mand yarn run test on con­sole will ex­e­cute the script named ‘test-code’ de­fined in your pack­age.json.

Yarn is highly com­pat­i­ble with npm. Projects built us­ing Yarn can still be in­stalled via npm, and vice versa. I have been us­ing it for a long time and till now have not found any prob­lems with it. The Yarn project is backed by com­pa­nies like Google and Face­book; so I be­lieve it will be de­vel­oped ac­tively.

Yarn is not sup­posed to re­place npm; rather, it pro­vides an im­proved set of fea­tures. It uses the same pack­age.json file and saves de­pen­den­cies to node_­mod­ules.

In con­clu­sion, both npm and Yarn are great de­pen­dency man­age­ment tools, but I pre­fer to use the lat­ter. Ref­er­ence https://yarnpkg.com

By: Man­ish Sharma

The au­thor has a mas­ter’s de­gree in com­puter ap­pli­ca­tions, and is cur­rently work­ing as a tech­nol­ogy ar­chi­tect at In­fosys, Chandi­garh. He can be reached at cloudtechgig@gmail.com.

Newspapers in English

Newspapers from India

© PressReader. All rights reserved.