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.
Hide `compile` and `execute` and provide a better API for browserified
applications:
- `boot.compileToBrowserify(options, bundler)` calls `compile` under
the hood and adds all instructions and scripts to the bundler.
- `bootBrowserApp(app)` is exported by loopback-boot when the module
is loaded in a browser, the function loads the instructions as
bundled by `compileToBrowserify`.
This new API hides all implementation details from the user and makes
it easy to add loopback-boot to any build script.
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.
Sub-directories of `models/` and `boot/` that cannot be required
(they don't have an index.js file) are silently skipped now.
This enables developers to put test files into `models/test/`.
When a script in `models/` or `boot/` exports a function which is not
a loopback.Model constructor, the bootstrapper immediatelly calls
this exported function wit the current `app` object.
This is providing a dependency injection mechanism for boot scripts,
so that they no longer need to know where to find the `app` object.
Note: the dependency injection is optional. Existing code getting
`app` reference via `require('../app')` will continue to work.
Support custom project layouts where model & datasource config files
are located in a different place from the app config.
Example:
# API server
server/app.config.json
server/datasources.json
# shared between server & client
models.json
models/
# isomorphic client
client/app.config.json
client/datasources.json
Modify loading of `appConfig` and `dataSourceConfig` to look for
the following files:
- app.json
- app.local.{js|json}
- app.{$env}.{js|json}
- datasources.json
- datasources.local.{js|json}
- datasources.{$env}.{js|json}
where $env is the value of `app.get('env')`, which usually defaults
to `process.env.NODE_ENV`.
The values in the additional files are applied to the config object,
overwritting any existing values. The new values must be value types
like String or Number; Object and Array are not supported.
Additional datasource config files cannot define new datasources,
only modify existing ones.
The commit includes refactoring of the config-loading code into
a standalone file.
Move `app.boot()` and its tests from loopback.
Fix jshint warnings.
Clean up unit tests - remove dependency on global variables created
by loopback's test/support.js
Miroslav Bajtoš
Fabien Franzen
Rand McKinney