bajtos

Keybase proof

I hereby claim:

• I am bajtos on github.
• I am bajtos (https://keybase.io/bajtos) on keybase.
• I have a public key ASAafG6dsFzJZ9SVtOS-eR08_Z5Rz4vyfYwRcs2OQ0tDgwo

To claim this, I am signing this object:

bajtos

'use strict';

const loopback = require('loopback');
const promisify = require('util').promisify;
const fs = require('fs');
const writeFile = promisify(fs.writeFile);
const mkdirp = promisify(require('mkdirp'));

const app = loopback();
const db = app.dataSource('db', {

bajtos

On experimental and in-progress pull requests

Introduction

A recent discussion on GitHub (link) triggered a discussion about the protocol to use for work that takes longer to complete and/or is experimental.

So far, it seems the team reached the following consenus:

• Pull request with a title prefixed with [WIP] are not done and ready for proper review. Early feedback is welcome though.
• Pull requests with a title prefixed with [DO NOT REVIEW] should not be looked at at all.

bajtos

How to develop LoopBack 3.0

Based on the current roadmap for v3.0, it will take several months until we will be able to cut the final 3.0.0 release. In the meantime, we need keep improving 2.x series that most customers are running on. This document describes the process.

Note that we are bumping up the major version to 3.0 primarily in order to allow us to make breaking changes, as ruled by semver. This is different from marketing practice of bumping up the major version to create an impression that the product has matured to a next level.

Branching strategy

Not all loopback modules have to be bumped to 3.0. We will keep using the current major version (typically 2.x) in all modules where we can preserve backwards compatibility. The major version will be bumped (and a major-version branch will be created) only at the point when we need to land a backwards incompatible (breaking) change.

bajtos

Coercion in strong-remoting - issues & changes

Changes introduced by v2.16.1

json body - array of booleans: non-boolean values (null, 0, 1, 2) are coerced to booleans. String items "true"/"false" are converted to true/false.

json body - arrays: scalar values are coerced to arrays, e.g. request body 1 is converted to [1].

form data - arrays: malformed JSON-like value is treated as verbatim string. E.g. ?arg={malformed} is converted to ['{malformed}'].

bajtos

The offline data access & synchronization is built from three components:

1. Change tracking
2. Replication of changes
3. Browser version of LoopBack

Setup

Enable change tracking

bajtos

var loopback = require('loopback');
var app = loopback();

var Car = loopback.createModel('Car');

Car.observe('before save', function(ctx) {
  console.log('before save %j', ctx);
  return Promise.resolve();
});

bajtos

This article provides much better and more detailed instructions:

http://www.nearform.com/nodecrunch/first-time-with-open-source/

---

Set up a local clone

Here is my setup, but feel free to use whatever works best for you. You need to run this once for each new repository (project) you fork on GitHub:

bajtos

THE STATUS IS NO LONGER TRUE, WE HAVE ADDED OPERATION HOOKS SINCE THEN.

SEE http://docs.strongloop.com/display/LB/Operation+hooks

---

Current status as of 2015-01-15

At the moment, LoopBack provides two kinds of hooks:

bajtos

// Call fs.stat over and over again really fast.
// Then see how many times it got called.
// Yes, this is a silly benchmark.  Most benchmarks are silly.

var path = require('path');
var common = require('../common.js');
var fs = require('fs');

var FILES = [
  require.resolve('../../lib/assert.js'),