remoteStorage.js 1.0.0 marks a big step for the library and project and considerably improves the developer experience across the board. However, this means that the ways to include and use it in your app changed in some significant ways.

This guide will show you what changed exactly and how to upgrade your app. Instead of duplicating information, it will mostly link to the shiny new documentation, which we're certain you will appreciate.

1. Including the library in your project

Instead of choosing between a bunch of different builds, you can now use our single new UMD build, which you can find in release/remotestorage.js. (There's a source map file in the same directory, which you can optionally link.)

We're now recommending npm as the preferred means of getting the library and managing its version. (But Bower is still available, too.)

We moved from global variables to proper JavaScript modules (any system you like). However, if you just link the release build from your HTML, you can still use globals.

4. Offering Dropbox and Google Drive as storage options

Dropbox and Google Drive are now officially supported as storage options! However, there are a bunch of known issues and caveats. Mainly, you can't use them for publicly sharing files yet, so make sure to disable sharing functions by looking at remoteStorage.backend, in case this applies to your app.

5. Data module changes

The API for defining data modules has changed in some ways: mainly, they are now just plain JavaScript objects instead of calling RemoteStorage.defineModule(), and you can load them into your remoteStorage instance either as config argument when creating it, or later via addModule().

The recommended way of sharing/publishing modules is now as one npm package per module (also as UMD builds)! This vastly improves the whole situation for both module contributors and consumers.