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

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

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

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

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

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

'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

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

exports['mocha snapshot checker always works for strings'] = `
foo
hello
world
`.slice(1, -1); // remove leading & trailing newlines

exports['mocha snapshot checker always works for objects'] = {
  key: 'valuex',
  number: 1,
};

bajtos

// Copyright IBM Corp. 2019. All Rights Reserved.
// Node module: loopback-next
// This file is licensed under the MIT License.
// License text available at https://opensource.org/licenses/MIT

'use strict';

const path = require('path');
const fs = require('fs-extra');