# List of notable changes made between 2.x and 3.0 All breaking changes must be described here. When adding a new entry, always describe the impact on users and instructions for upgrading applications from 2.x to 3.0. ## loopback-datasource-juggler was moved from peerDependencies to dependencies Originally, we (ab)used peer dependencies to ensure there is only one instance of loopback-datasource-juggler in the dependency tree, so that there is only one singleton instance of model registry. This was very fragile and might not have worked in certain edge cases. We have reworked loopback-datasource-juggler and connectors to not rely on a single juggler instance anymore. As the last step, juggler became a regular dependency. https://github.com/strongloop/loopback/issues/275 When upgrading application from previous loopback versions, simply remove loopback-datasource-juggler from your dependencies. ## always use bluebird as promise library In version 3.0, we always use bluebird as our promise library instead of `global.Promise`. We consider Bluebird API a part of LoopBack API from now on, you are welcome to use any Bluebird-specific methods in your applications. If you are using LoopBack with a custom promise implementation provided via `global.Promise`, you will have to check all places where you are using non-standard promise API and update them to use Bluebird API instead. Please see [Related code change](https://github.com/strongloop/loopback/pull/1896) here. ## new method of defining remoting metadata In 2.0, remote methods were defined as: ``` methods: { staticMethod: { isStatic: true, http: { path: '/static' } }, instanceMethod: { isStatic: false, http: { path: '/instance' } } } ``` For 3.0, the isStatic flag is no longer required and will be determined from the method name. Method name starting with "prototype." will be the same as having isStatic flag set to false. ``` methods: { staticMethod: { http: { path: '/static' } }, 'prototype.instanceMethod': { http: { path: '/instance' } } ``` Please see [related code change](https://github.com/strongloop/loopback/pull/2174) here. ## remove `Change.handleError` `Change.handleError` is now removed as it was used inconsistenly for a subset of possible errors only. All Change methods will report all errors to the caller via the callback. Use PersistedModel to report change-tracking errors via the existing method PersistedModel.handleChangeError. This method can be customized on a per-model basis to provide different error handling. Please see [related code change](https://github.com/strongloop/loopback/pull/2308) here. ## remove unused user properties The following properties are removed from the built-in User model in 3.0: - credentials - challenges - status - created - lastUpdated Developers that are relying on these properties, can redefine them in `user.json` or equivalent model.json as follow: ```json { "name": "MyUser", "base": "User", "properties": { "credentials": { "type": "object" }, "challenges": { "type": "object" }, "status": "string", "created": "date", "lastUpdated": "date" } } ``` Please see [Related code change](https://github.com/strongloop/loopback/pull/2299) here. ## Remove getters for Express 3.x middleware Express 4.x stopped bundling commonly-used middleware. To simplify migration of LoopBack 1.x applications (powered by Express 3.x) to LoopBack 2.x (powered by Express 4.x), we created getter properties to allow developers to keep using the old convention. We have removed these getters in LoopBack 3.0, here is the full list of removed properties together with the middleware module name to use instead: - `loopback.compress` - use `require('compression')` instead - `loopback.timeout` - use `require('connect-timeout')` instead - `loopback.cookieParser` - use `require('cookie-parser')` instead - `loopback.cookieSession` - use `require('cookie-session')` instead - `loopback.csrf` - use `require('csurf')` instead - `loopback.errorHandler` - use `require('errorhandler')` instead - `loopback.session` - use `require('express-session')` instead - `loopback.methodOverride` - use `require('method-override')` instead - `loopback.logger` - use `require('morgan')` instead - `loopback.responseTime` - use `require('response-time')` instead - `loopback.favicon` - use `require('serve-favicon')` instead - `loopback.directory` - use `require('serve-index')` instead - `loopback.vhost` - use `require('vhost')` instead We have also removed `loopback.mime`, which was always set to `undefined`. See [loopback#2349](https://github.com/strongloop/loopback/pull/2394). ## Remove `loopback#errorhandler` We have removed `loopback#errorhandler` middleware, users should use `strong-error-handler` directly. ```js // server/middleware.json { // ... "final:after": { "strong-error-handler": {} } } // server/middleware.development.json { "final:after": { "strong-error-handler": { "params": { "debug": true } } } ``` See also strong-error-handler's [options](https://github.com/strongloop/strong-error-handler#options) and the [related code change](https://github.com/strongloop/loopback/pull/2411). ## Remove current context API and middleware We have removed the following current-context-related APIs: - `loopback.getCurrentContext` - `loopback.createContext` - `loopback.runInContext` Additionally, `loopback#context` middleware and `remoting.context` server config were removed too. #### Upgrading from 2.x to 3.x When upgrading from LoopBack 2.x, you need to disable or remove `remoting.context` configuration in your server config. ```js { "remoting": { "context": false, // or remove completely // etc. }, // etc. } ``` Without this change, you will see the following error on the first HTTP request received: ``` Unhandled error for request GET /api/Users: Error: remoting.context option was removed in version 3.0. See https://docs.strongloop.com/display/APIC/Using%20current%20context for more details. at restApiHandler (.../node_modules/loopback/server/middleware/rest.js:44:15) at Layer.handle [as handle_request] (.../node_modules/express/lib/router/layer.js:95:5) ``` #### Setting up "current context" in 3.x To setup "current context" feature in your LoopBack 3.x application, you should use [loopback-context](https://www.npmjs.com/package/loopback-context) module: 1. Add `loopback-context` to your dependencies 2. Configure the new context middleware in your `server/middleware-config.json` file ```json { "initial": { "loopback-context#per-request": {} } } ``` 3. Replace all usages of `loopback.getCurrentContext` with the following: ```js // at the top of your file var LoopBackContext = require('loopback-context'); // in your code var ctx = LoopBackContext.getCurrentContext(); if (ctx) { // use the context } ``` See also [loopback#2564](https://github.com/strongloop/loopback/pull/2564) and the official [documentation](https://docs.strongloop.com/display/APIC/Using+current+context) ## Remove sugar for creating models `app.model(modelName, settings)`, a sugar for creating non-existing model, is now removed in favor of promoting use of: - `app.registry.createModel(modelName, properties, options)` to create new model - `app.model(modelCtor, config)` to update existing model and attach it to app Please see [related code change](https://github.com/strongloop/loopback/pull/2401) here.