generator-loopback version 1.1.1

Running yo loopback:acl and choosing the following options:

yo loopback:acl
[?] Select the model to apply the ACL entry to: (all existing models)
[?] Select the ACL scope: All methods and properties
[?] Select the access type: All (match all types)
[?] Select the role: All users
[?] Select the permission to apply: Explicitly deny access

Throws the following error:

/usr/local/lib/node_modules/generator-loopback/node_modules/loopback-workspace/node_modules/longjohn/dist/longjohn.js:185
throw e;
^
Error: The query filter true is not an object
at DataAccessObject._normalize (/usr/local/lib/node_modules/generator-loopback/node_modules/loopback-workspace/node_modules/loopback-datasource-juggler/lib/dao.js:368:11)
at Function.find (/usr/local/lib/node_modules/generator-loopback/node_modules/loopback-workspace/node_modules/loopback-datasource-juggler/lib/dao.js:668:10)
at module.exports.yeoman.generators.Base.extend.acl (/usr/local/lib/node_modules/generator-loopback/acl/index.js:146:30)
at /usr/local/lib/node_modules/generator-loopback/node_modules/yeoman-generator/lib/base.js:341:43
at /usr/local/lib/node_modules/generator-loopback/node_modules/yeoman-generator/node_modules/async/lib/async.js:551:21
at /usr/local/lib/node_modules/generator-loopback/node_modules/yeoman-generator/node_modules/async/lib/async.js:227:13
at iterate (/usr/local/lib/node_modules/generator-loopback/node_modules/yeoman-generator/node_modules/async/lib/async.js:1

The README in the client directory states that it's the location for client HTML, etc.
However, by default, the generated server (specifically, server/boot/root.js) displays server status:

// Install a `/` route that returns server status
var router = server.loopback.Router();
router.get('/', server.loopback.status());
server.use(router);

If the README is correct, shouldn't it have something like app.use(express.static(__dirname + '/client')); instead?

E.g. ask the user for the project description, license, repository type & URL.

See also strongloop/loopback-workspace#177

Is this intended?

Recent changes (e.g. strongloop/loopback-boot#149 and https://github.com/strongloop/loopback-example-app/pull/77) enable an app to load loopback.rest declaratively in middleware.json and loopback.explorer via component-config.json.
The application generator needs to reflect this.

So by default, the generated middleware.json should have the following to load REST and status middleware:

"routes": {
    "loopback#rest": {
      "paths": ["${restApiRoot}"]
    },
    "loopback#status" : {
      "paths" : ["/"]
    }
  },
...

NOTE: I'm not 100% sure about the status middleware config above. @bajtos can you confirm that is correct?

The above replaces server/boot/rest-api.js and server/boot/root.js which are no longer needed AFAIK.

Also, the generator should create a server/component-config.json that looks like this:

{
  "loopback-explorer": {
    "mountPath": "/explorer"
  }
}

The above replaces server/boot/explorer.js, which is no longer needed AFAIK.

When I run

slc loopback:model Whatever

My common folder seems to be updated alright, but no change to the model-config.json file.

Any ideas why?

Although it's only a warning, it certainly doesn't give a great first impression for someone just creating the sample app.

$ slc --version
strongloop v2.10.3 (node v0.10.36)
├── [email protected]
├── [email protected] (5a43a57)
├─┬ [email protected] (c945bd1)
│ └── [email protected]
├── [email protected]
├── [email protected] (5e25e21)
├── [email protected] (315d448)
├── [email protected] (aab3dbb)
├── [email protected]
└── [email protected] (96a7f70)

$ slc loopback:example
...
Create initial project scaffolding
Add datasource geo
Add model Car
(node) warning: possible EventEmitter memory leak detected. 11 listeners added. Use emitter.setMaxListeners() to increase limit.
Trace
    at addListener (events.js:160:15)
    at run (/usr/local/lib/node_modules/strongloop/node_modules/generator-loopback/node_modules/yeoman-generator/lib/base.js:444:21)
    at module.exports.yeoman.generators.Base.extend._runGeneratorWithAnswers (/usr/local/lib/node_modules/strongloop/node_modules/generator-loopback/example/index.js:621:22)
    at module.exports.yeoman.generators.Base.extend._createProperty (/usr/local/lib/node_modules/strongloop/node_modules/generator-loopback/example/index.js:524:10)
    at /usr/local/lib/node_modules/strongloop/node_modules/generator-loopback/example/index.js:482:16
    at iterate (/usr/local/lib/node_modules/strongloop/node_modules/async/lib/async.js:149:13)
    at /usr/local/lib/node_modules/strongloop/node_modules/async/lib/async.js:160:25
    at setExtraOptions (/usr/local/lib/node_modules/strongloop/node_modules/generator-loopback/example/index.js:541:40)
    at null.<anonymous> (/usr/local/lib/node_modules/strongloop/node_modules/generator-loopback/node_modules/yeoman-generator/lib/base.js:382:5)
    at Queue.g (events.js:180:16)

This should be very similar to the ModelDefinition generator. See the component wiki for details.

I’m trying to create the ACL entry to allow authenticated users to write to the create property to recreate https://github.com/strongloop/loopback-getting-started-intermediate/blob/master/common/models/review.json#L44 as provided by @superkhau.

Here is what I entered:

$ slc loopback:acl
? Select the model to apply the ACL entry to: Review
? Select the ACL scope: A single method
? Enter the method name: create
? Select the role: Any authenticated user
? Select the permission to apply: Explicitly grant access

But in review.json this yields:

{
      "accessType": "EXECUTE",
      "principalType": "ROLE",
      "principalId": "$authenticated",
      "permission": "ALLOW",
      "property": "create"
    }

But it’s supposed to be

{
      "accessType": "WRITE",
      "principalType": "ROLE",
      "principalId": "$authenticated",
      "permission": "ALLOW",
      "property": "create"
    },

The accessType should be WRITE not EXECUTE.

This affects the LoopBack Getting Started part 2 tutorial http://docs.strongloop.com/display/LB/Define+access+controls.
Please let me know when this is changed so I can update the docs.

I'm organising the models in subfolders inside common/models, registering each one on model-config.json (_meta.sources property). The application runs and works fine, but these models are not showed on slc loopback:* commands, just the others ones (default from LB).

strongloop: 2.10.3
loopback: 2.13.0
juggler: 2.19.0

Hi.

I'm using Windows and trying to use loopback for the first time.

I wasn't able to install the stongloop module, and this troubleshooting page suggested to use the loopback generator directly in this case.
So I ran npm install -g yo and npm install -g generator-loopback successfully.

When I run yo loopback in a directory I immediately get this error:

C:\Program Files\nodejs\node_modules\generator-loopback\app\index.js:46
    var originalMethod = Workspace.copyRecursive;
                                  ^
TypeError: Cannot read property 'copyRecursive' of undefined
    at module.exports.yeoman.generators.Base.extend.injectWorkspaceCopyRecursive (C:\Program Files\nodejs\node_modules\generator-loopback\app\index.js:46:35)
    at C:\Program Files\nodejs\node_modules\generator-loopback\node_modules\yeoman-generator\lib\base.js:395:14
    at processImmediate [as _immediateCallback] (timers.js:317:15)

Can you please help? Thanks

We should add the slc loopback:operation-hook command to add operation hook to models.

See #90

As a developer, I would like to configure a model when or after it is defined. It's desirable to have a separate generator to configure a model.

loopback:model should prompt for the base class to use for the new model. It should offer a default based on datasource connector type (e.g. Model for no datasource, PersistedModel for database connectors).

https://github.com/strongloop/generator-loopback/blob/master/model/index.js#L58

I would like to add a generator to scaffold boot scripts, something like:

slc loopback:boot
What kind of boot script would you like to generate?
>o sync
o async
What do you want to name your boot script? <enter name>
[generate <name>.js] in /server/boot with the following contents:
#sync
module.exports = function(app) {

}
#async
module.exports = function(app, cb) {

  cb();
};

@bajtos @raymondfeng @ritch Thoughts?

Connected to #93

For example:

$ slc loopback:relation
[?] Select the model to create the relationship from: Customer
[?] Relation type: (Use arrow keys)
❯ has many 
  belongs to 
  has and belongs to many 
  has one 

Please add hasManyThrough relation type.

A follow-up for #47.

We have already serialized writes with strongloop/loopback-workspace@6099e91. But the requirement is to guarantee write requests to be placed in order. The granularity of writes at the moment is too high. For example, if two of the following calls are made in parallel:

1. model.accessControls.create --- adding an acl entry to modelDef.acls
2. model.relations.create --- adding a relation entry to modelDef.relations

The content of 1 is: { acls: [{...}], relations: {}}
The content of 2 is: { acls: [{...}], relations: {{...}}

There will be race condition if 2 is scheduled to the write queue before 1. As a consequence, we'll lose the newly added relation.

Maybe the workspace models should just work directly with the cache and have an independent worker to replicate the entries to filesystem.

Workaround

API consumers has to serialize CrUD operations to prevent this race condition.

From strongloop/strongloop#182 reported by @ppoliani

Quite often when I run commands like loopback:relation where you need to select an option, the arrow keys don't work at all. I need to rerun the command multiple time and if i'm lucky i get it work properly.

Connected to #96

Currently i see this bug when i run command to create new model, as my testing this bug happen by inconsistent code between slc loopback:model and slc run. This is explain like like this:
1- slc loopback:model need all model.json/ "indexes" setting must be an array.
2- slc run need all model.json/ "indexes" setting must be an object.
=> So you only run correctly in case 1 but not correctly in case 2 and otherwise.

 slc loopback:model
[?] Enter the model name: MyModel
[?] Select the data-source to attach MyModel to: mongodb (mongodb)
[?] Expose MyModel via the REST API? Yes
[?] Custom plural form (used to build REST URL): 
Let's add some MyModel properties now.

Enter an empty property name when done.
[?] Property name: title
   invoke   loopback:property

/Users/user/node/lib/node_modules/strongloop/node_modules/generator-loopback/node_modules/loopback-workspace/node_modules/loopback-datasource-juggler/lib/list.js:25
    throw new Error(util.format('Items must be an array: %j', items));
          ^
Error: Items must be an array: {"location_index":{"location":"2dsphere"}}
    at new List (/Users/user/node/lib/node_modules/strongloop/node_modules/generator-loopback/node_modules/loopback-workspace/node_modules/loopback-datasource-juggler/lib/list.js:25:11)
    at List (/Users/user/node/lib/node_modules/strongloop/node_modules/generator-loopback/node_modules/loopback-workspace/node_modules/loopback-datasource-juggler/lib/list.js:9:12)
    at ModelConstructor.ModelBaseClass._initProperties (/Users/user/node/lib/node_modules/strongloop/node_modules/generator-loopback/node_modules/loopback-workspace/node_modules/loopback-datasource-juggler/lib/model.js:216:28)
    at ModelConstructor.ModelBaseClass (/Users/user/node/lib/node_modules/strongloop/node_modules/generator-loopback/node_modules/loopback-workspace/node_modules/loopback-datasource-juggler/lib/model.js:41:8)
    at ModelConstructor (/Users/user/node/lib/node_modules/strongloop/node_modules/generator-loopback/node_modules/loopbacPhams-MacBook-Air:api user$

I already have a loopback application but it keeps asking whether I want to create one.

D:\demo>dir
 Volume in drive D is Windows
 Volume Serial Number is 9ED5-A315

 Directory of D:\demo

07/14/2014  03:16 PM    <DIR>          .
07/14/2014  03:16 PM    <DIR>          ..
07/14/2014  03:16 PM             3,203 app.js
07/14/2014  03:16 PM                98 app.json
07/14/2014  03:16 PM               339 datasources.json
07/14/2014  03:16 PM    <DIR>          models
07/14/2014  03:16 PM             1,569 models.json
07/14/2014  03:16 PM    <DIR>          node_modules
07/14/2014  03:16 PM               335 package.json
               5 File(s)          5,544 bytes
               4 Dir(s)  24,755,081,216 bytes free

D:\demo>yo loopback:model

     _-----_
    |       |    .--------------------------.
    |--(o)--|    |  Let's create a LoopBack |
   `---------´   |       application!       |
    ( _´U`_ )    '--------------------------'
    /___A___\
     |  ~  |
   __'.___.'__
 ´   `  |° ´ Y `

[?] What's the name of your application? (demo) ^C

when you scaffold a new loopback app with a project/directory name already in the arguments, it should still tell you to change directory before scaffolding your model

slc loopback myapp

the output says...

slc loopback:model next
it should first still say
cd myapp

The generator slc loopback:* is erasing the definitions of remote methods present in model's json files (common/models). BTW, the files are reformatted, losing other changes made.

When finished the generator executions (for any parameters, like models, acls, etc), the property "methods" of all files of models has its contents replaced with []. Although this wrong behaviour, the replacement by an array is conceptually wrong IMHO, since strongloop/loopback@019488f .

cd $root/server
slc loopback:datasource $datasourceName
Go through the prompts.
Then nothing is added to datasources.json

Should give a warning or something like "Run this command again in the root dir" or detect the root dir automatically.

When running yo loopback:model a side effect of the model creation is minor updates to various json config files read by the generator.

package.json order of properties

My package.json file had the title property listed before the name property. After running yo loopback:model and adding a new model, the order was reversed.

newline at end of file removed

My projects leverage an .editorconfig file with the rule insert_final_newline = true. After running yo loopback:model and adding a new model, the following files had final newline removed:

• package.json
• server/config.json
• server/datasources.json
• server/model-config.json - other required updates to this file are made though the final newline is stripped in updating

While the changes seem insignificant, it will require attention when the files mentioned are in source control.

With the exception of model-config.json, is it necessary to write to these files?

Enter an empty property name when done.
? Property name: dose_man_hour
   invoke   loopback:property
? Property type: number
? Required? Yes

Let's add another SubActivity property.
Enter an empty property name when done.
? Property name: dose_man_day
   invoke   loopback:property
? Property type: number
? Required? Yes

Let's add another SubActivity property.
Enter an empty property name when done.
? Property name: norm_man_hour
   invoke   loopback:property
(node) warning: possible EventEmitter memory leak detected. 11 change listeners added. Use emitter.setMaxListeners() to increase limit.
Trace
    at addListener (events.js:179:15)
    at run (/Users/paulomcnally/.nvm/v0.12.0/lib/node_modules/generator-loopback/node_modules/yeoman-generator/lib/base.js:444:21)
    at invoke (/Users/paulomcnally/.nvm/v0.12.0/lib/node_modules/generator-loopback/node_modules/yeoman-generator/lib/actions/invoke.js:38:20)
    at null.<anonymous> (/Users/paulomcnally/.nvm/v0.12.0/lib/node_modules/generator-loopback/model/index.js:176:12)
    at null.<anonymous> (/Users/paulomcnally/.nvm/v0.12.0/lib/node_modules/generator-loopback/node_modules/yeoman-generator/lib/base.js:221:7)
    at PromptUI.onCompletion (/Users/paulomcnally/.nvm/v0.12.0/lib/node_modules/yo/node_modules/inquirer/lib/ui/prompt.js:69:10)
    at AnonymousObserver.Rx.AnonymousObserver.AnonymousObserver.completed (/Users/paulomcnally/.nvm/v0.12.0/lib/node_modules/yo/node_modules/inquirer/node_modules/rx/dist/rx.js:1929:12)
    at AnonymousObserver.Rx.internals.AbstractObserver.AbstractObserver.onCompleted (/Users/paulomcnally/.nvm/v0.12.0/lib/node_modules/yo/node_modules/inquirer/node_modules/rx/dist/rx.js:1866:14)
    at AutoDetachObserverPrototype.completed (/Users/paulomcnally/.nvm/v0.12.0/lib/node_modules/yo/node_modules/inquirer/node_modules/rx/dist/rx.js:4604:23)
    at AutoDetachObserver.Rx.internals.AbstractObserver.AbstractObserver.onCompleted (/Users/paulomcnally/.nvm/v0.12.0/lib/node_modules/yo/node_modules/inquirer/node_modules/rx/dist/rx.js:1866:14)
? Property type: (Use arrow keys)
❯ string 
  number 
  boolean 
  object 
  array 
  date 

I only added multiples properties to a model.

In order to implement components as documented here, we need to add the ability to configure both middleware and components in a loopback app. This depends on these entities / APIs in the loopback-workspace.

Things to configure:

• add component model sources to server/model-config.json

We should add the slc loopback:remote-method command to scaffold custom remote methods.

See #90

Subtasks

• First cut implementation
• Http mapping of arguments (see https://docs.strongloop.com/display/public/LB/Remote+methods?src=search&src=search#Remotemethods-HTTPmappingofinputarguments)
• Add isStatic
• Check input valid
• Add unit tests
• Either add a dummy method implementation to model js file or alternatively print instructions including dummy method code to the output after the JSON metadata was updated.
• Add http verb(major and custom)
• Make modelName an argument

Connected to strongloop/strong-arc/issues/685

In a directory my-app, run slc loopback, default application name is apparently derived by replacing - with , becomingmy app, but that is invalid. The application name cannot "contain special characters (/@+%: )".

It appears that valid characters in the name, -, are being replaced with invalid characters, unnecessarily.

Example:

sam@samtu:~/w/sn/loopback-minimum % slc loopback
... pretty picture...
[?] Enter a directory name where to create the project: .
[?] What's the name of your application? (loopback minimum) 
>> Application name cannot contain special characters (/@+%: ): loopback minimum

Hey,

Just saying that your contribution, @bajtos, was merged a few months ago. ;) Thanks again!
Related to:

Cheers

before, the generated or updated json files would be nicely formatted but now the contents appear in a single line.

Currently npm install spits out some deprecation warnings related to some nested dependencies. It looks like upgrading to [email protected] will clear them up.

npm WARN deprecated [email protected]: the module is now available as 'css-select'
npm WARN deprecated [email protected]: the module is now available as 'css-what'

Originally reported in strongloop/strongloop#243

Based on this discussion in the LoopBack forum, it would be nice to have the option to select the output directory when creating a new model with yo loopback:model foo.

It was noted that in the near future there will be options to select the model destination. It would be great to have this look at the _meta sources values in model-config.json and use them.

When you scaffold an app, by default the status middleware gets triggered not only for the root URL, but for any URL, except for valid API URLs. So http://0.0.0.0:3000/, http://0.0.0.0:3000/foo, http://0.0.0.0:3000/foo/bar/, and http://0.0.0.0:3000/foo/bar.html all trigger the status middleware.

This is a change to the behavior of the default scaffolded app, which used to trigger the status middleware ONLY on the root URL, http://0.0.0.0:3000/. I'm not sure this is really a problem, but it does seem odd that it gets triggered for any invalid URL--you only see the error stack trace when you request an invalid URL that starts with /api. I haven't found any way to actually generate a 404 error (UrlNotFoundError) in the default scaffolded app.

Perhaps this isn't an issue, since it's only with the default scaffolded app, but perhaps it would make more sense to make the status path be /status so it's not a "catchall" route.

@raymondfeng suggested I open an issue.

If you provide an <appname> argument to slc loopback it ignores the arguments and fails unexpectedly. You would expect that if you provide the argument in the command line, then the tool should use that as the default when it prompts you for the directory, but it still uses . as the default. If you accept the default, then the tool fails with a stack trace as shown below.

It should use the <appname> you provided as the default, so you're not required to enter the app name twice. At the very least, it should catch the error and give a meaningful error message.

Reproduce:

$ slc loopback foo
     _-----_
    |       |    .--------------------------.
    |--(o)--|    |  Let's create a LoopBack |
   `---------´   |       application!       |
    ( _´U`_ )    '--------------------------'
    /___A___\    
     |  ~  |     
   __'.___.'__   
 ´   `  |° ´ Y ` 

[?] Enter a directory name where to create the project: .
[?] What's the name of your application? foo

ValidationError: The `ModelConfig` instance is not valid. Details: `name` is not unique.
    at /usr/local/lib/node_modules/strongloop/node_modules/generator-loopback/node_modules/loopback-workspace/node_modules/loopback-datasource-juggler/lib/dao.js:155:16
    at ModelConstructor.<anonymous> (/usr/local/lib/node_modules/strongloop/node_modules/generator-loopback/node_modules/loopback-workspace/node_modules/loopback-datasource-juggler/lib/validations.js:473:13)
    at ModelConstructor.next (/usr/local/lib/node_modules/strongloop/node_modules/generator-loopback/node_modules/loopback-workspace/node_modules/loopback-datasource-juggler/lib/hooks.js:66:12)
    at done (/usr/local/lib/node_modules/strongloop/node_modules/generator-loopback/node_modules/loopback-workspace/node_modules/loopback-datasource-juggler/lib/validations.js:470:25)
    at /usr/local/lib/node_modules/strongloop/node_modules/generator-loopback/node_modules/loopback-workspace/node_modules/loopback-data

Version info:

$ slc --version
strongloop v2.9.2 (node v0.10.32)
├── [email protected]
├─┬ [email protected]
│ └── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
└── [email protected]

Hi Guys,

   When running "yo loopabck:model", during the process I get "Model not found: MyModel"... What's going on? Any workaround for this guys?

C:\Users\Acaspita\Documents\MyLoopbackProject\server>yo loopback:model
[?] Enter the model name: MyModel
[?] Select the data-source to attach MyModel to: db (memory)
[?] Expose MyModel via the REST API? Yes
[?] Custom plural form (used to build REST URL):
Let's add some MyModel properties now.

Enter an empty property name when done.
[?] Property name: Name
invoke loopback:property
Model not found: MyModel

C:\Users\Acaspita\AppData\Roaming\npm\node_modules\generator-loopback\node_modules\loopback-workspace\node_modules\longjohn\dist\longjohn.js:185
throw e;
^
Error: Model not found: MyModel
at module.exports.yeoman.generators.Base.extend.findModelDefinition (C:\Users\Acaspita\AppData\Roaming\npm\node_modules\generator-loopback\property\index.js:56:20)
at C:\Users\Acaspita\AppData\Roaming\npm\node_modules\generator-loopback\node_modules\yeoman-generator\lib\base.js:341:43
at C:\Users\Acaspita\AppData\Roaming\npm\node_modules\generator-loopback\node_modules\yeoman-generator\node_modules\async\lib\async.js:551:21
at C:\Users\Acaspita\AppData\Roaming\npm\node_modules\generator-loopback\node_modules\yeoman-generator\node_modules\async\lib\async.js:227:13
at iterate (C:\Users\Acaspita\AppData\Roaming\npm\node_modules\generator-loopback\node_modules\yeoman-generator\node_modules\async\lib\async.js:134:13)
at C:\Users\Acaspita\AppData\Roaming\npm\node_modules\generator-loopback\node_modules\yeoman-generator\node_modules\async\lib\async.js:145:25
at C:\Users\Acaspita\AppData\Roaming\npm\node_modules\generator-loopback\node_modules\yeoman-generator\node_modules\async\lib\async.js:229:17
at C:\Users\Acaspita\AppData\Roaming\npm\node_modules\generator-loopback\node_modules\yeoman-generator\node_modules\async\lib\async.js:556:34
at C:\Users\Acaspita\AppData\Roaming\npm\node_modules\generator-loopback\node_modules\yeoman-generator\lib\base.js:327:11

at Conflicter. (C:\Users\Acaspita\AppData\Roaming\npm\node_modules\generator-loopback\node_modules\yeoman-generator\lib\util\conflicter.js:74:5)

at all (C:\Users\Acaspita\AppData\Roaming\npm\node_modules\generator-loopback\node_modules\loopback-workspace\node_modules\loopback-datasource-juggler\lib\connectors\memory.js:321:11)
at EventEmitter.<anonymous> (C:\Users\Acaspita\AppData\Roaming\npm\node_modules\generator-loopback\node_modules\loopback-workspace\connector.js:196:17)
at g (events.js:180:16)
at EventEmitter.emit (events.js:92:17)
at done (C:\Users\Acaspita\AppData\Roaming\npm\node_modules\generator-loopback\node_modules\loopback-workspace\connector.js:101:14)
at C:\Users\Acaspita\AppData\Roaming\npm\node_modules\generator-loopback\node_modules\async\lib\async.js:254:17

at connector.loadFromFile (C:\Users\Acaspita\AppData\Roaming\npm\node_modules\generator-loopback\node_modules\loopback-workspace\connector.js:92:10)
at connector.all (C:\Users\Acaspita\AppData\Roaming\npm\node_modules\generator-loopback\node_modules\loopback-workspace\connector.js:193:13)
at Function.find (C:\Users\Acaspita\AppData\Roaming\npm\node_modules\generator-loopback\node_modules\loopback-workspace\node_modules\loopback-datasource-juggler\lib\dao.js:757:34)
at DataAccessObject.all (C:\Users\Acaspita\AppData\Roaming\npm\node_modules\generator-loopback\node_modules\loopback-workspace\node_modules\loopback-datasource-juggler\lib\dao.js:382:25)
at actions.loadModels (C:\Users\Acaspita\AppData\Roaming\npm\node_modules\generator-loopback\lib\actions.js:89:36)
at C:\Users\Acaspita\AppData\Roaming\npm\node_modules\generator-loopback\node_modules\yeoman-generator\lib\base.js:341:43
at C:\Users\Acaspita\AppData\Roaming\npm\node_modules\generator-loopback\node_modules\yeoman-generator\node_modules\async\lib\async.js:551:21
at C:\Users\Acaspita\AppData\Roaming\npm\node_modules\generator-loopback\node_modules\yeoman-generator\node_modules\async\lib\async.js:227:13

As discussed previously, the generator should prompt the user to generate client/public/index.html and serve it up by default in place of the server status on the / route.

See the component example wiki for details.

A lot of Node and LoopBack 1.x users are used to running the application with node app. For the current project layout, we have to run node server/server.

Is generator missing some files? like server.js?

I am trying to generate sample app from getting started loopback guide.
Generator is making wrong tree.

bash-3.2$ tree -I node_modules
.
├── common
│   └── models
│       ├── person.json
│       └── test.json
├── package.json
└── server
    ├── config.json
    ├── datasources.json
    └── model-config.json

also when i try to scaffold model
it fails after property name:

Enter an empty property name when done.
[?] Property name: price
   invoke   loopback:property

as mentioned in #35

https://github.com/transedward/loopback-sandbox(the same box I tried reduplicating with my question)

I used slc loopback:relation with two built-in models: AccessToken and User as you can see
but After finishing, there is nothing would be shown to proven there are relations between these two models

As you can see, git status show there is nothing.

if we use slc loopback:model to build a new model then it would show on common/models
then after slc loopback:relation, we can see the relation on relation property

what is the best practice of this problem, create every model u gonna use? but then what is built-in for?
or is there some 'magic' after we relation built-in models? then what if we wanna change afterwards? how can we know it's actually effecting?

Modify sub-generators like slc loopback:model to support projects with no server component (e.g. a component project).

As a developer, I would like to configure a policy with a generator.

yo loopback prints the following instructions at the moment:

 Create a model in your app
    $ yo loopback:model

  Optional: Enable StrongOps monitoring
    $ yo strongops

  Run the app
    $ yo run .

A better version:

  Create a model in your app
    $ yo loopback:model

  Optional: Enable StrongOps monitoring
    $ slc strongops

  Run the app
    $ node .

Looks like the property relationship scope is not available when creating properties. This might be an issue in loopback itself or the workspace.

See also strongloop/loopback#483
/cc @bajtos @kraman

When creating a new app with slc loopback, the instructions it provides at the end are outdated:

Next steps:

  Change directory to your app
    $ cd test1

  Create a model in your app
    $ slc loopback:model

  Optional: Enable StrongOps monitoring
    $ slc strongops

  Run the app
    $ slc run .

Need to:

• Remove the line about StrongOps, when its deprecated. Maybe replace with something about Arc?
• Remove the line about using slc run because we are deprecating it and not telling people to use it any more. Should tell them to use node . or slc start.