loopback-boot/test/fixtures/browser-app/model-config.json

{
  "_meta": {
    "sources": [
      "./models",
      "loopback/common/models"
    ]
  },
  "Customer": {
    "dataSource": "db"
  },
  "ProductUmd": {
    "dataSource": "db"
  }
}
Rework model configuration 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. 2014-06-13 11:14:43 +00:00			`{`
Skip definitions of built-in loopback models LoopBack built-in models are special: they follow the loopback-boot structure and provide `common/models/{name}.json` files, but they are also automatically loaded (created) by loopback. This change modifies `executor` to recognize built-in models and do not redefine them. 2014-10-21 08:06:28 +00:00			`"_meta": {`
			`"sources": [`
			`"./models",`
compiler: support module-relative model sources Interpret model sources in the same way how `require.resolve` interprets the path: - values starting with `./` and `../` are relative to the file where they are specified - other values are relative to node modules folders This way it's possible to specify a source `loopback/common/models` and have it resolved to whatever place the loopback is installed. 2014-10-21 14:51:17 +00:00			`"loopback/common/models"`
Skip definitions of built-in loopback models LoopBack built-in models are special: they follow the loopback-boot structure and provide `common/models/{name}.json` files, but they are also automatically loaded (created) by loopback. This change modifies `executor` to recognize built-in models and do not redefine them. 2014-10-21 08:06:28 +00:00			`]`
			`},`
Rework model configuration 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. 2014-06-13 11:14:43 +00:00			`"Customer": {`
			`"dataSource": "db"`
Support es2015 module exports (Babel, TypeScript) Detect when a script file is an es2015 module created by a transpiler like Babel or TypeScript and use the `default` export instead of `module.exports` in such case. The following artefacts support the new syntax now: - boot scripts - components - middleware - model scripts 2017-06-18 12:49:16 +00:00			`},`
			`"ProductUmd": {`
			`"dataSource": "db"`
Rework model configuration 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. 2014-06-13 11:14:43 +00:00			`}`
			`}`