未加星标

Thoughts on yarn

字体大小 | |
[前端(javascript) 所属分类 前端(javascript) | 发布者 店小二05 | 时间 2016 | 作者 红领巾 ] 0人收藏点击收藏
Table of contents Yarn is a better npm client Tiny modules exploding Tiny modules, big dependency trees Being centralised is a problem Security is still a problem Understanding licensing is a problem Yarn is a better npm client

Yarn announced itself ata new package manager for javascript. Eventually the project may look at creating a registry but for now it is simply a better npm client. It is a drop in replacement for the official npm client and offers a global cache and better parallelisation. From my crude tests and anecdotal reports from friends and colleagues it is much faster and more efficient than the standard npm client.

The problems outlined in the announcement are largely related to deployment and scaling the npm client in enterprise settings. Yarn seems to have re-solved some of the problems that the npm client has already addressed. Switch npm-shrinkwrap for a lockfile for example. It seems a shame that there was no aspiration to contribute to the open source npm client but multiple clients are no bad thing.

Given developers want reliability and speed if the yarn project can succeed in improving download speeds and reliability I fully expect it to become the default. More interesting for me is that yarn is an expression that not everything is rosy in the JavaScript package management ecosystem.

Tiny modules exploding

It is indisputable thatnpmhas been a runaway success. The platform has seen explosive growth, has scaled and has become a daily tool for software developers.

npm users downloaded 1.4 billion packages in the last 7 days, 5.2 billion in the last 28 days, and 48 billion in the last 365 days. pic.twitter.com/pXaPTB6s1p

― Laurie Voss (@seldo) September 30, 2016

150 new authors are now publishing packages every day.

This is a graph of how many people publish a package to npm for the very first time, per day 150-200 new authors per day! pic.twitter.com/MEBY1qNFTJ

― Laurie Voss (@seldo) October 5, 2016

The explosive growth is not surprising given that small modules are favoured over large monolithic code bases but the growth is indisputable and impressive. The npm service has matured to become stable and able to scale.

Tiny modules, big dependency trees

The Node.js ecosystem has promoted writing tiny modules. Along with the upside of tiny reusable modules comes massive dependency trees. Have a look at the yarn dependency graph as an example.


Thoughts on yarn

I have seen the large dependency trees cause build servers to lock up or fail which is frustrating when you are trying to ship code. Furthermore package versioning can lead to brittle builds if you do not specify exact versions or use npm shrinkwrap.

With so many tiny userland modules there are issues of modules authors not following semantic versioning or just removing packages. One such example is left-pad a 52 line module for left padding a string. This module wasremoved from the registryby the author breaking deployment pipelines and a number of major projects that depended on it. The package was later restored and the fallout documented by npm. This incident led to many running their own npm cache to mitigate against deployments being disrupted.

Being centralised is a problem

The history of npm is one moving from a hobby project and one of the original Node.js package managers. Remember kiwi anyone? npm eventually became the default choice and coupled withIsaac Schluetertaking over as the benevolent dictator of the Node.js project it became official.

The npm project then took $2.6 Million in seed funding and became a for-profit organisation whilst maintaining an open source approach. This has been universally good for the Node.js ecosystem but has resulted in one for-profit organisation owning the hosting of the registry. The npm team have done a fantastic job in scaling the registry and maintaining an excellent service but I can’t help feeling that the release of yarn is an expression that this model is less than perfect.

Far better for me would be to have a decentralised registry that allows replication and mirroring around the world similar to the way major linux distributions run their registries. This reduces reliance one on single registry provider and reduces issues of scale. Packages are verified by checksums and signing so files can be hosted and downloaded from anywhere. Far from ruining npm’s business model I feel there would still be opportunities to offer private registries and generate revenue. Perhaps we are too far down the road now though.

Security is still a problem

Whilst npm does perform sha1sum checking packages are unsigned. Often authors will declare dependencies with a greater than syntax. Using something like ~1.2.3 will install anything greater than 1.2.3 and less than 1.3.0. As such it would be quite feasible for an npm author account to be compromised and for a new package version to be released that is less than 1.3.0. This version would proliferate around project installs, build servers and production sites as npm install is run.

A package rimfafall was released to highlight this issue but the conclusion was ‘You are responsible for what you require’. With dependencies trees reaching to tens of thousands of modules this simply isn’t feasible.

Whilst signing packages has been discussed it has not progressed so package installers are still vulnerable to an npm account being compromised.

Understanding licensing is a problem

A while back I was asked to perform an audit on a relatively small project for an large enterprise who were interested in understanding the Open Source licences used in a project. There are packages available to output this information. Let us suppose that an organisation requires that no GPL licenses are used in a project. Given the epic dependency trees of projects it is very hard to know this and unless you lock versions of packages you install this can change as you run npm install .

Conclusion

Currently yarn is just a better npm client. The registry it uses is just a proxy to the main npm registry but the fact it does not point to the npm registry directly suggests that there may be some aspiration to include reworking the registry in the project.

The announcement of yarn is an expression of the maturity of JavaScript, Node.js and npm. Seen as a better npm client it offers a drop in replacement to resolve a number of issues experienced at scale. Seen as an expression that npm is not perfect it opens up potential flux and innovation in JavaScript package management. I would love to see package signing and a distributed registry addressed. Until then security and a single organisation owning the distribution of packages remain problems waiting to happen.

Have an update or suggestion for this article? You can edit it here and send me a pull request.

Tags

本文前端(javascript)相关术语:javascript是什么意思 javascript下载 javascript权威指南 javascript基础教程 javascript 正则表达式 javascript设计模式 javascript高级程序设计 精通javascript javascript教程

主题: Node.jsJavaScriptJavaLinux
分页:12
转载请注明
本文标题:Thoughts on yarn
本站链接:http://www.codesec.net/view/483709.html
分享请点击:


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 前端(javascript) | 评论(0) | 阅读(29)