Tag Archives: npm

Yarn: A new package manager for JavaScript

Facebook fixes several problems with npm; will yarn become the new standard, will npm make changes, or will developers not care?

 

We’ve used the npm client successfully at Facebook for years, but as the size of our codebase and the number of engineers grew, we ran into problems with consistency, security, and performance. After trying to solve for each issue as it came up, we set out to build a new solution to help us manage our dependencies more reliably. The product of that work is called Yarn — a fast, reliable, and secure alternative npm client.

Read more at Facebook Code

Changes to npm’s unpublish policy

npm decides to keep their unpublish functionality but puts in place rules to prevent breaking other packages

 

npm writes on their blog:

One of Node.js’ core strengths is the community’s trust in npm’s registry. As it’s grown, the registry has filled with packages that are more and more interconnected.

A byproduct of being so interdependent is that a single actor can wreak significant havoc across the ecosystem. If a publisher unpublishes a package that others depend upon, this breaks every downstream project that depends upon it, possibly thousands of projects.

Last Tuesday’s events revealed that this danger isn’t just hypothetical, and it’s one for which we already should have been prepared. It’s our mission to help the community succeed, and by failing to protect the community, we didn’t uphold that mission.

We’re sorry.

Read the whole post

Why I Left Gulp and Grunt for npm Scripts

Gulp and Grunt leave you dependent on plugin authors, stick you with debugging, and provide disjointed documentation. Why not just use JavaScript?

Cory House writes:

I know what you’re thinking. WAT?! Didn’t Gulp just kill Grunt? Why can’t we just be content for a few minutes here in JavaScript land? I hear ya, but…

I’ve found Gulp and Grunt to be unnecessary abstractions. npm scripts are plenty powerful and often easier to live with.

Read more from the source: Medium

npm Private Modules

For $7 a month, you can get the convenience of npm without making all your internal modules public

 

When you pay for private modules, you can:

– Host as many private packages as you want

– Give read access or read-write access for those packages to any other paid user

– Install and use any packages that other paid users have given you read access to

– Collaborate on any packages that other paid users have given you write access to

Read the details on npmjs.com

JavaScript I/O Brings ES6 to the Node Community

Are you sad that Joyent isn’t forward thinking with node.js? Start using io.js, a community-driven fork of node.js

 

io.js is a JavaScript platform built on Chrome’s V8 runtime. This project began as a fork of Joyent’s Node.js™ and is compatible with the npm ecosystem.

Why? io.js aims to provide faster and predictable release cycles. It currently merges in the latest language, API and performance improvements to V8 while also updating libuv and other base libraries.

This project aims to continue development of io.js under an ” open governance model” as opposed to corporate stewardship.

io.js has moved to Semver. The choice to release as 1.0.x was not to signify that io.js should be considered production-ready, but because it was a significant enough release from Node.js™ to warrant a major version increment.

Read more from the source: iojs.org

npm@2.0.0 released – The npm Blog

npm 2.0.0 is a major version change but don’t be afraid, your code probably won’t break

 

npm maintainer Forrest Norvell (@othiym23) introduces npm 2.0.0:

“Last week, I released npm@2.0.0. If you’ve been using npm@1.4, it’s a substantial update, but that’s not why it’s 2.0.0. npm@1.0.1 was released on April 30th, 2011 – three and a half years ago.”

Notable changes include:

– Ability to pass arguments into scripts

– Scoped packages

– Bearer token auth

– Node 0.8+ is required

– Numerous bugfixes

Read more from the source: npmjs.org