js-ipfs 0.42.0 released

by Alex Potsides on 2020-04-14

🔦 Highlights

Smaller, faster, more reliable

js-IPFS@0.42.0 has been released, bringing a host of bug fixes and other small stability improvements.

It reduces the size of the minified bundle by 7.5% for faster downloads and more responsive web apps!

We’ve also merged some of our repos together which were logically intertwined. Our hope is that this will make contributing easier and encourage experimentation as there will be fewer PRs to juggle to land a piece of functionality!

🤖 Automated publishing of RCs

Release Candidate builds of js-ipfs and js-ipfs-http-client are now being published to npm with every build of master, so you can try out the very bleeding edge with:

$ npm install -g ipfs@next
or
$ npm install ipfs-http-client@next

This will download and install a version of js-ipfs and/or js-ipfs-http-client created from the last successful build of master with no GitHub URLs in the production dependency tree.

🛳️ Updated Docker containers

Publishing to Docker Hub has been restored so you can get a container running the latest and greatest js-ipfs with:

$ docker pull ipfs/js-ipfs

You can also pull pre-releases at any time with:

$ docker pull ipfs/js-ipfs:next

Check out all the releases at: https://hub.docker.com/r/ipfs/js-ipfs

✨New features

The MFS CLI now supports nanosecond mtimes, use it with the following commands:

$ jsipfs mkdir /directory --mtime 1000 --mtime-nsecs 5

--mode and --mtime are now also supported when piping files to jsipfs add:

$ cat ./file.txt | jsipfs add --mode 0500

🔨 Breaking changes

🦟 Bugs fixed

💍 One PR to rule them all

A common observation made about IPFS development is that there are so many repos to gain knowledge of, it’s hard to know how everything fits together and where a problem might originate, all of which makes it hard to start contributing.

Contributors will sometimes spend precious time crafting one PR, only to be told they need to make additional PRs to repos they didn’t even know existed in order to land their initial change. This often ends up being too much of a barrier for developers who have external time pressures or have other shiny PRs to push on.

Features must be staged across multiple releases from multiple repos, and any of these releases have the potential to block unrelated work streams in other repos & projects purely through human error - bugs may be introduced, or perhaps a follow up piece of work becomes necessary. With multiple releases from multiple repos it also becomes hard to roll back these changes; it’s a last resort tactic but denying us it’s use because our module release process is complicated is an artificial constraint of our own making.

To start to address this we’ve consolidated js-ipfs, js-ipfs-mfs, js-ipfs-multipart, js-ipfs-http-client and interface-js-ipfs-core into one repository.

This made sense because a given IPFS feature is typically implemented in js-ipfs, exposed over http by the http client and tests are added to the interface suite to ensure everything works together - now you will be able to make that sort of change in one PR instead of three!

It’s our hope that this will go some way towards simplifying IPFS development and will encourage new contributors to pitch in and help us build the platform to power the distributed web.

🗺️ What’s next?

To get a better view on what’s coming up in js-ipfs releases, we’ve put a Project Roadmap together that contains headline features organised in the order we hope them to land.

Only large features are called out in the roadmap, expect lots of small bugfix releases between the roadmapped items!

😍 Huge thank you to everyone that made this release possible

🙌🏽 Want to contribute?

Would you like to contribute to the IPFS project and don’t know how? Well, there are a few places you can get started:

⁉️ Do you have questions?

The best place to ask your questions about IPFS, how it works, and what you can do with it is at discuss.ipfs.io. We are also available at the #ipfs channel on Freenode.

Comments