Categories
JavaScript npm Package Management

npm 5: Lockfiles Finally Arrive

npm 5 is shipping with package-lock.json, and the irony isn't lost on anyone. After Yarn forced npm's hand by introducing lockfiles in October 2016, npm is finally catching up. This is competition working exactly as intended—but it also exposes some uncomfortable truths about JavaScript dependencies.

What Changed

npm 5 introduces package-lock.json which locks down the entire dependency tree. Run npm install on any machine with the lockfile, and you get identical versions of every package, including transitive dependencies. This matches what Yarn's yarn.lock has been doing since launch.

{
  "name": "my-app",
  "version": "1.0.0",
  "lockfileVersion": 1,
  "dependencies": {
    "lodash": {
      "version": "4.17.4",
      "resolved": "https://registry.npmjs.org/lodash/-/lodash-4.17.4.tgz",
      "integrity": "sha1-eCA6TRwyiuHYbcpkYONptX9AVa4="
    }
  }
}

The performance improvements are also significant. npm 5 is noticeably faster than npm 4, though still not quite matching Yarn's speed.

Categories
JavaScript Package Management Tooling

Yarn: npm Has Competition

Facebook and Google released Yarn yesterday—a new package manager that uses npm's registry but promises faster, more reliable, more secure installations. The collaboration between tech giants and focus on npm's pain points suggests npm has serious problems.

Whether Yarn succeeds depends on execution and whether developers tolerate another package manager.

What Yarn Fixes

Categories
JavaScript npm Open Source

The left-pad Incident: npm’s Single Point of Failure

This week, the JavaScript ecosystem had a wake-up call. A developer unpublished a tiny npm package—11 lines of code—and broke thousands of projects including major ones like Babel and React. The incident exposed fundamental fragility in how npm dependencies work.

The technical fix was quick. The implications aren't.

What Happened

Categories
JavaScript Node.js Tooling

npm 3: Flatter Dependencies (Finally)

npm 3 is in beta, and the biggest change is how it handles dependencies. Instead of deeply nested trees, npm 3 tries to flatten them. This seemingly small change has significant implications for how we use npm, especially for frontend code.

The Nested Dependency Problem

Categories
JavaScript Tooling Web Development

npm: The Accidental Frontend Package Manager

Something interesting is happening: developers are abandoning Bower and installing frontend dependencies with npm. This seems wrong—npm was designed for Node.js, and browser code has different constraints. But the trend is real, and understanding why reveals tensions in how we think about frontend packaging.

The Two Package Managers Problem

Categories
JavaScript Tooling Web Development

Bower and the Frontend Package Management Problem

Twitter released Bower six months ago, and it's gaining traction for managing frontend dependencies. But using it raises an interesting question: why does frontend need a separate package manager? The answer reveals fundamental differences in how we think about server-side versus client-side code.

The npm Model Doesn't Work for Browsers

Categories
JavaScript Node.js Server-Side

Introduction to Node.js: JavaScript on the Server

Introduction

JavaScript on the server isn't new. We've had Rhino, SpiderMonkey, and other JavaScript engines for years. But Node.js is different, and it's generating serious excitement.

Released last year by Ryan Dahl, Node.js takes Chrome's V8 JavaScript engine and wraps it with APIs for file I/O, networking, and other server-side tasks. The result is a platform for building scalable network applications using JavaScript.