When executor passes the instruction to loopback methods,
loopback modifies the data. Since we are loading the data using
`require` such changes affects also code that calls
`require` for one of the instructions files.
This change adds a deep clone step to prevent this issue.
The new loopback project layout adds a concept of components like
'rest server' and 'isomorphic client', each component having its own set
of boot files. The name `app.json` is confusing, since it is configuring
a component, not the app (which is the whole project).
Rework the way how models are configured, the goal is to allow
loopback-boot to automatically determine the correct order
of the model definitions to ensure base models are defined
before they are extended.
1. The model .js file no longer creates the model, it exports
a config function instead:
```js
module.exports = function(Car, Base) {
// Car is the model constructor
// Base is the parent model (e.g. loopback.PersistedModel)
Car.prototype.honk = function(duration, cb) {
// make some noise for `duration` seconds
cb();
};
};
```
2. The model is created by loopback-boot from model .json file.
The .js file must have the same base file name.
3. The `boot()` function has a new parameter `modelSources` to
specify the list of directories where to look for model definitions.
The parameter defaults to `['./models']`.
As a side effect, only models configured in `models.json` and their
base clases are defined. This should keep the size of the browserified
bundle small, because unused models are not included.
Breaking change.
In the new 2.x project layout, definition of loopback Models is out of
scope of the boot process. The bootstrapper only configures existing
models - attaches them to a dataSource and the app object.
Split bootLoopBackApp into two steps:
- compile
- execute
Most of the changes are just shuffling the existing code around.
What has changed:
- `loopback.autoAttach()` is called after `models/*` are required.
The calls were made in the opposite order before this commit.