If you use npm private packages then there's a very serious data leak that you should be aware of. Metadata for private packages was accidentally made available from the public replication endpoint.
I've included the full announcement below:
We need to notify you of a serious security incident that was discovered today, July 2nd.
Starting on June 26th, scoped package metadata was available via the public replication endpoint from npm. This means that third parties were aware of metadata about scoped packages, including private packages. This metadata was limited to:
versions and version publication dates
It's important to make clear that this does not include the packages themselves: package contents and source code were never available. User information such as passwords and billing information was not part of the information that leaked.
If your package metadata contained sensitive information, please take mitigation steps immediately. Because this information replicated, we will be making a public disclosure of the leak. However, to give you time to react (we are aware that it is a holiday weekend in the US) we will be holding off on the public announcement until Monday, July 6th.
We apologize wholeheartedly for this mistake and have taken steps to prevent this error. We are conducting a thorough review of our processes to avoid both this specific problem and any similar errors in the future.
Thank you for your continued support of npm. If you have any further questions or concerns please reach out to firstname.lastname@example.org.
Check your readme files and package names to ensure nothing sensitive has been leaked. This is unfortunate, but npm is handling it promptly and professionally. With any service you rely on for commercial work, like GitHub, Bitbucket, npm, and CDNs, you should review what you publish before it's stored on remote systems.
Sindre Sorhus is the author of over 600 modules on npm. He recently wrote a long GitHub comment about why we should use small modules, and I asked for permission to reproduce the text on DailyJS. Read on to learn about why small modules make programming easier, and why it's not really about lines of code.
People get way too easily caught up in the LOC (Lines Of Code) argument. LOC is pretty much irrelevant. It doesn't matter if the module is one line or hundreds. It's all about containing complexity. Think of node modules as lego blocks. You don't necessarily care about the details of how it's made. All you need to know is how to use the lego blocks to build your lego castle.
By making small focused modules you can easily build large complex systems without having to know every single detail of how everything works. Our short term memory is finite. Other people can reuse these modules and when a module is improved or a bug is fixed, every consumer benefits.
Imagine if PC manufacturers all made their own CPUs. Most would do it badly. The computer would be more expensive and we would have slower innovation. Instead most use Intel, ARM, etc.
Small modules are made possible by how npm works. The beauty of being able to use nested dependencies means I don't have to care what dependencies a dependency I use have. That's powerful.
Some years ago -- before Node.js and npm -- I had a large database of code snippets. I used to copy-paste these snippets into projects when I needed them. They were small utilities that sometimes came in handy. npm is now my snippet database. Why copy-paste when you can require? Packaging and naming a module also has the benefit of having a clear intent. Furthermore, fixing a bug in a snippet means updating one module instead of manually fixing all the instances where the snippet is used.
As an example, I have a module called negative-zero. Its job is to tell me if a number is -0. Normally you wouldn't have to care about this, but I've found it useful. How do you figure out if a number is -0? Well, that's easy: x === 0 && 1 / x === -Infinity. Or is it? Do you really want to have to know how and why this works? I would rather require negative-zero and focus on other things.
Another example. Chalk is one of the most popular modules on npm. What you might not realize is that it's actually a collection of modules. It depends on a module for detecting if the terminal supports color, for getting the ansi escape codes, etc. All of this could have been just embedded in the main module, and it probably is in many cases. But that would mean anyone else wanting to create an alternative terminal string styling module would have to reinvent the wheel. By having supporting modules, people can easily benefit from Chalk and maybe even help improve Chalk by improving one of the dependencies.
Yet another example. I have a module called user-home which gets the user's home directory. You might think it would be simpler to just do process.platform === 'win32' ? process.env.USERPROFILE : process.env.HOME. And most people just that. But first, why force everyone to know how to get the home directory? Why not use a "lego block"? What you also might not realize is that this check is incomplete. On Windows you should also check process.env.HOMEDRIVE + process.env.HOMEPATH and you might also want to do additional checks. Lego blocks.
Do you make your own shoes? No, you buy them in a store. Most don't care how the shoe is made. Just how good it fits.
I want programming to be easier. Making it easier to build durable systems. And the way forward in my point of view is definitely not reinventing everything and everyone making the same stupid mistakes over and over.
Written by Sindre Sorhus, reproduced with permission and republished with edits by the DailyJS authors.
On Monday the Node Long-term Support Working Group met to discuss plans for Node's future release schedule. The plan is described as a strawman LTS plan, meaning it's preliminary and hasn't yet been approved. There's a discussion on GitHub about it that I found through this Tweet (retweeted by @rvagg which is seemingly how I learn everything about io.js/Node):
The plans are based on several assumptions -- again, nothing is official yet. One assumption is that the next major and officially supported Node release will be from the merged io.js/Node project, and will follow io.js's versioning. Subsequent major releases will be yearly, and will transition into maintenance after 18 months. There's a handy visualisation of the release schedule:
Relä (GitHub: joakimbeng/relae, License: MIT, npm: relae) by Joakim Carlstein is a library for fetching data from RESTful servers using React components. It can fetch data from a base URL, but can also filter data.
If you've already injected JSON into the initial page load, then you can bootstrap it with Relae.bootstrap(data).
To use Relä, you need to wrap a React component with Relae.createContainer. This is where you pass the REST API URL and filtering options:
This project is based on React Relay -- you can compare the API from the Relay Newsfeed blog post. The author has planned more features, but has already implemented some cool stuff like caching.
If you find yourself generating lists of class names (often done in React projects), then have you ever wondered if there's a better way to do it? Luke William Westby has a suggestion: ClassNameBuilder (GitHub: lukewestby/class-name-builder, License: MIT, npm: class-name-builder). This library offers a chainable API for manipulating class name strings. It supports conditional expressions and merging instances together:
Mesh (GitHub: mojo-js/mesh.js, License: MIT, npm: mesh) by Craig Condon is a data synchronisation library that caters for server-side and client-side requirements. The author has pitched it as the "underscore of data", meaning it's a highly focused library that you can drop in to existing applications.
It covers both storage and transit. For example, in the browser you could use localStorage, and Socket.IO to broadcast data to other clients. The supported databases are in-memory, localStorage, and MongoDB. If you want to use Mesh with a database that isn't supported, then you can write a new database adapter based on a CRUD API.
The API is based on CRUD operations and Node-like streams. Let's say you want to store data to local storage:
var mesh = require('mesh');
var storage = require('mesh-local-storage');
var bus = storage();
You can now insert data (persisted to local storage) like this:
The main motivation behind this library is to make data sources interoperable with one another, so I'd like to see what this looks like with a React application in the client, and a MongoDB-based REST API on the server.