By Charlie Midtlyng

Translation: Crazy geek

Original text: javascript. Christmas / 2019/10

Reproduced without permission

Every team must make decisions during the development process. This usually involves YARN, NPM, or other tools for building and packaging javascript code. Some developers are eager to move in a certain direction, and sometimes they spend a lot of time trying, making decisions that actually have little impact on their work.

First, to understand why we made an interesting decision, we need to look at the history of package management in javascript.

  • Before NPM: Front-end dependencies were saved to a repository and manually downloaded from 📁
  • 2010:npmPublish and supportnodejs📦
  • 2012:npmHas increased dramatically — mainly because ofBrowserifysBrowser support 🎉
  • 2012:npmYou have a competitorbower, it fully supports the browser 💻
  • 2012-2016: The number of front-end project dependencies doubled 🤯
  • 2012-2016: Building and installing front-end applications is getting slower 🐢
  • 2012-2016.: Lots of (repetitive) dependencies are stored in the magicnode_modulesIn the nested folder ☢️
  • 2012-2016.:rm -rf node_modulesBecome the most commonly used command by front-end developers. 🗑
  • 2015:bowerLost to thenpm 💀
  • 2015:node_modulesModified to flat file structure! 🕸
  • 2016:left-padIt made headlines at the time 👈
  • 2016:yarnRelease 🚀
    • supportnpm 和 bowerwarehouse
    • yarn.lockAbility to lock installed versions and provide deterministic dependencies. No longerrm -rf node_modules!
    • yarn installThe time it takes is 1npm installHalf (without caching)
    • Caching and offline mode make the build process almost time-free
  • 2016:npmreleaseshrinkwrap🧯
    • Try to handle dependency locking
    • Unfortunately, a number of mistakes and promises beyond its administrative capacity have led to the tool’s reputation falling
  • 2017:npm5 release 🔓
    • package-lock.jsonIt’s their new tool,shrinkwrapPut aside
    • package-lock.jsonTo start with theyarnsLock file contention
  • 2018:npm ciRelease 🛬
    • Use directlypackage-lock.jsonBuilding code
    • No costly dependency security analysis and versioning
    • Greatly reduces build time on the build server!
  • 2018:npm6 release 👮 ♀ ️
    • npmCheck for security holes in dependencies you want to install
    • yarn 和 npmThere is no significant difference in the build time of
  • 2019:tinkEnter beta mode 🦋
    • Avoid the use ofnode_modulesInstead, create a file with hash values for each dependency in the project
    • It’s not ready for production
  • .

Ah… 🥵

As we have seen, NPM was inspired (and forced?) after YARN was released. Lots of good tools and mechanics have been developed. Yarn has been credited with addressing some of the important issues related to NPM and began to put pressure on its competitors in 2016. Package processing speed, security, and certainty are essential features that allow today’s developers to focus on creating value and not argue over the two tools.

Conclusion 🤔

For the sake of convenience, I recommend that most teams (who must make many other more important technical decisions) choose the simplest option — NPM. It ships with Node and currently handles package management in a good enough way.

Are there always exceptions? 🧐

Yarn Workspaces is a popular alternative when using Monorepo, and NPM does not provide an equivalent alternative. Lerna is a software package that also supports the use of Monorepos and can be used with NPM and YARN (with workspaces).

PNPM 🥉

PS: It should be mentioned that PNPM is the third option for package manager. If PNPM’s selling point is that if a package has already been downloaded to a local repository, it won’t be downloaded again — this is similar to Maven dependency management in Java. At the time of this writing, PNPM is not as mature as YARN or NPM and cannot be put into production.

Welcome to pay attention to the front end public number: front end pioneer, free front-end engineering utility kit.