Let environment variables override configuration set by config.json
and/or app.set()
Behavior changes
- datasources.json now support dynamic configuration through
env-vars and config.json
- component-config.json will first consider env-var
for resolving dynamic conf, then fallback to config.json
- middleware.json will first consider env-var for resolving
dynamic conf, then fallback to config.json
- for all the dynamic confg, unresolved conf will return as `undefined`
Example:
Consider the following server/datasources.json
```
{
"mysql" : {
"name" : "mysql_db",
"host" : "${MYSQL_DB_HOST}",
...
}
}
```
Now you can provide the parameter through
an environment variable:
```
$ MYSQL_DB_HOST=127.0.0.1 node .
```
or you can set the value in server/config.json
```
{
"MYSQL_DB_HOST": "127.0.0.1"
}
```
Fix executor to always emit the "booted" event and call the callback
in the next tick of the event loop, regardless of whether there are any
async boot scripts.
Before this change, adding a listener for "booted" event was cumbersome:
boot(app);
if (app.booting)
app.on('booted', handler);
else
handler();
With the fix in place, one can simply write the following:
boot(app);
app.on('booted', handler);
App variables can now be specified in component-config.json using
the ${var} format. The value of var is looked up using app.get().
This allows loopback explorer and other loopback components which
require app variables, to be loaded declaratively using
component-config.json.
App variables can now be specified in middleware.json using the ${var}
format. The value of var is looked up using app.get().
This allows loopback.rest and other loopback middleware which require
app variables, to be loaded declaratively using middleware.json.
When loading middleware configured in "middleware.json", loopback-boot
used to require() the full path to middleware's module main file,
for example "node_modules/strong-express-metrics/index.js".
This is breaking strong-agent probes, as it's difficult to detect
when the intercepted module (e.g. "strong-express-metrics") was loaded.
This commit modifies the compiler to omit the tail (the path to the
module main source file) when requiring middleware.
Port can't be number checked to support iisnode. Using a parseInt()
or number isNumber function won't work if we want to support iisnode
which uses named pipes for ports (ex. \\.\pipe\mypipe)
Extend the options argument of boot/compile to allow the developer
to supply custom model definitions (to replace the result of
findModelDefinitions). Together with the existing options.models,
it allows to specify all model-related data and still use the benefits
which loopback-boot provides (most notably loading models in order
defined by inheritance, i.e. base models are loaded before models that
are extending them).
Use the global `isFinite` function to find the first valid port
number. This is the same behaviour as `_.isFinite` in lodash@2.x.
As a result, only values that are a valid number are accepted, e.g.
"0" is accepted but "0xy" is not.
- Ensure `app.booting` is initially `undefined`
- Ensure `app.booting` is set to true during boot execution
- Ensure `app.booting` is set to false upon boot completion
This prevents an occurence where an error is completely swallowed if a script
required by loopback-boot has a bad require() call. The script is never ran
but execution continues.
Load configuration of components from `component-config`
and configure all components as specified.
Sample JSON:
{
"loopback-component-foobar": {
"option1": "value1",
"option2": "value2"
}
}
The component is expected to export the following function:
module.exports = function(app, options) { /* ... */ };
Remove duplicated entries in the array of boot scripts to run.
Because the bootDirs defaults to process.cwd(), if the user manually
includes scripts in the same directory, without specifying a bootDir,
those scripts will be included multiple times.
Introduce a convention for specifying relative paths in middleware
params: values prefixed with `$!` and starting with `./` or `../`
are resolved relatively to `middleware.json`.
Example:
{
"files": {
"loopback#static": {
"params": "$!../client"
},
"loopback#static": {
"params": "$!./public"
}
}
}
When the middleware name (path) is in the format {module}#{filename},
loopback-boot resolves the path by trying multiple locations and
using the first one that exists:
- {module} and check the {filename} property of the exports
-> e.g. loopback.rest
- {module}/server/middleware/{filename}
-> e.g. loopback/server/middleware/rest
- {module}/middleware/{filename}
-> e.g. loopback/middleware/rest
Values in any other format will bypass this resolution algorithm and
they will be used in the original form:
- a full path in a module: loopback/server/middleware/rest
- a relative path: ./middleware/custom, ./custom, ../logger
- an absolute path: /usr/local/lib/node_modules/compression
juehou
Loïc Mahieu
David Cheung
Miroslav Bajtoš
Miroslav Bajtoš
Farid Neshat
Amir Jafarian
Miroslav Bajtoš
yorkie
Ryan Graham
Simon Ho
Hage Yaapa
Hack Sparrow
Raymond Feng
Jonathan Sheely
Miroslav Bajtoš
Pradnya Baviskar
Shlomi Assaf
Krishna Raman
Simon Ho
Clark Wang
Samuel Reed
Eric Satterwhite