Provide a "start" command

[superkhau]

@lazaridis-com commented on Sun Feb 12 2017

The lb command line tool should have a start command.

This would simplify the usage, especially for newcomers (they don't know much about the underlying stack).

Additionally, it would be more consistent in general (one command-line tool, "lb").

Current Status

$ lb app todo
$ cd todo 
$ lb model
$ node .

With "start" Command

$ lb app todo
$ cd todo 
$ lb model
$ lb start

[superkhau]

@lazaridis-com Good idea. Just to confirm though, lb start should basically map to npm start (which may or may not map to node . depending on how we organize things -- like for our project which is really node server/server) correct?

[raymondfeng]

I'm not sure about the value of lb start as it might mean multiple different things, such as:

• node .
• npm start
• strong-pm
• pm2
• docker run

[superkhau]

lb start as it might mean multiple different things

That's why I suggested mapping to npm start so the user can define what it means via typical node conventions (ie. package.json). Of course, the value is debatable as this is just sugar.

[superkhau]

Additionally, it would be more consistent in general (one command-line tool, "lb").

@lazaridis-com I don't think this will ever be the case unless we wrap all the npm commands as you'll still need to npm install your dependencies etc, meaning it'll never be "one command-line tool").

IMO, better to leave NPM to what it does best -- ie. unix philosophy number 1: "Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features"."

That said, maybe closing this feature request is a better idea. @raymondfeng Thoughts? Starting the app seems like NPM/Node's scope of work.

[superkhau]

@lazaridis-com It's more about do one thing well, which is to be the best API framework, not the best JavaScript runtime or Node.js package manager.

That said, we're open to opinions. Do you suggest shielding the user away from NPM and Node.js completely? Ie. What if you want to install a dependency for your LoopBack project? Do you now want a lb install command that maps to npm install? What about when you want to remove dependencies? Do you put in lb rm that maps to npm rm for that? And so forth.

[superkhau]

@lazaridis-com Thank you for your detailed thoughts. It's an interesting perspective. I'm all for giving the people what they want. At the same time, we also try to scope down the features only the absolutely necessary. Of course the perspectives differ depending on how experienced you are as you described.

Let's get some more input here. As for my opinion now, I don't mind sugar api that delegates off to NPM/Node commands if it's simple to implement (and if you're willing to contribute it since it's obviously not at the top of our current priorities, but I respect that it might be on yours).

@bajtos What are you thoughts?

[bajtos]

I personally think that lb start is redundant and node . is more than good enough.

[superkhau]

@lazaridis-com Gonna close this as rejected, we can reopen this if there are more requests for this feature.

As a workaround, you're free to create your own bash alias (assuming you're on a unix-like OS) to do what you want:

lb() {
  if [[ $@ == "start" ]]; then
    node .
  else
    lb $@
  fi
}

Note: I haven't tested the above, but it's probably something along those lines.

[superkhau]

@lazaridis-com -- @raymondfeng and @ritch would be closer to that role, but I work closely with @bajtos on community issues. It is definitely something we're addressing, but alas resources are pulling us in many directions. The project is definitely not dead and there is a lot of work being done on the next version of LoopBack. Your concern in #3199 is definitely one of the top priorities on our list. I will comment a bit more over there.