The JavaScript blog.


node project-management modules apps slides presentations react

NewSprint, Spectacle

Posted on .


NewSprint (GitHub: rodati/newsprint, License: MIT, npm: newsprint) from Rodati is a command-line Node tool for generating a mobile-friendly email based on Trello cards.

I use Trello for project management, and for a while I archived each week (or sprint) into a list so it was easy for management to see what we've completed recently. This process could be automated with NewSprint, by sending an email with card summaries. The emails look very nice, and I like the fact it uses a command-line tool with JSON files for configuration.



Ken Wheeler sent in Spectacle (GitHub: FormidableLabs/spectacle, License: MIT, spectacle), a React-powered presentation library.

With Spectacle you can write slides with JSX. It supports tags like <Deck>, <Slide>, and there are even layout tags for making text appear in the right place without too much fiddling about with CSS. Here's a very basic example of a slide:

export default class extends React.Component {  
  render() {
    return (

It even supports a presenter view, so you can see the next side and the current time. If you're currently addicted to React then this will probably be preferable to messing around in Keynote/PowerPoint/etc.


iojs node security

Security Updates: Node 0.12 and io.js

Posted on .

Today security updates for Node 0.12, io.js 2.3 and io.js 1.8 were released due to a UTF-8 decoding bug in V8:

Here's the technical overview from the io.js Medium post:

Kris Reeves and Trevor Norris pinpointed a bug in V8 in the way it decodes UTF strings. This impacts Node at the Buffer to UTF8 String conversion and can cause a process to crash. The security concern comes from the fact that a lot of data from outside of an application is delivered to Node via this mechanism which means that users can potentially deliver specially crafted input data that can cause an application to crash when it goes through this path. We know that most networking and filesystem operations are impacted as would be many user-land uses of Buffer to UTF8 String conversion. We know that HTTP(S) header parsing is not vulnerable because Node does not convert this data as UTF8. This is a small consolation because it restricts the way HTTP(S) can be exploited but there is more to HTTP(S) than header parsing obviously. We also have no information yet on how the various TLS terminators and forward-proxies in use may potentially mitigate against the form of data required for this exploit.

Node 0.10 is not affected. Thanks to Rod Vagg for letting me know about this!


security node npm privacy

npm: Scoped Package Metadata Leak

Posted on .

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:

  • package names
  • 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 support@npmjs.com.

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.


node iojs

Node: Long-Term Support Working Group

Posted on .

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:

Node strawman LTS

The author (James M Snell) just posted that 0.12 might see a slightly shorter 0.12 LTS release, so if you're (hypothetically) planning maintenance work based on these plans then you might want to take that into account. I very much hope this comes together, because a major Node release that includes io.js would be pretty exciting for server-side JavaScript programmers.


node npm

npm 3

Posted on .

npm's job is to keep you out of dependency hell, not put you in it.

The beta of npm 3 has been released, and I'm running it right now:

$ npm --version

If you want to try it, use npm install -g npm@3.0-latest but be careful: not only is it a beta, but you can also break your npm installation if the global install fails. How do I know? My permissions were messed up on /usr/local/bin/npm, so when I tried to upgrade I saw "Error: EACCES, unlink ... node_modules/npm/.eslintrc". From that point npm was no longer in my $PATH... I actually reinstalled my current version of Node to fix it quickly, but I can imagine people getting very confused and frustrated about seeing command not found: npm.

If you're wondering what npm 3 will do for you, then a big thing is actually the UI: installation has a different appearance (it's more like npm ls), and npm outdated has changed. The "location" column shows which module required a dependency rather than where it is on disk.

Big projects should feel a little saner thanks to less nesting:

Your dependencies will now be installed maximally flat. Insofar as is possible, all of your dependencies, and their dependencies, and THEIR dependencies will be installed in your project's node_modules folder with no nesting.

If you make use of peerDependencies for modules that you distribute, you should be aware that they don't install dependencies anymore. Instead the user is warned about an unmet dependency.

This shifts the responsibility for fulfilling peer dependencies from library framework / plugin maintainers to application authors, and is intended to get users out of the dependency hell caused by conflicting peerDependency constraints. npm's job is to keep you out of dependency hell, not put you in it.

npm 3 is considered a rewrite by the authors. The level of redevelopment means we'll hopefully see some rich new features in the near future for front-end developers. If you're like me and you use Node for lightweight server-side apps, with rich client-side logic, then this will appeal to you.

The changelog for version 3 is actually very good and you really should read the full thing if you manage Node projects or distribute modules with npm.