Nativescript-cli: Make `tns run` use livesync by default

[tjvantoll]

I’ve spent some time over the holidays playing with a variety of frameworks, and one thing I’ve noticed is that livesync functionality is increasingly the default behavior that developers expect. React Native watches by default, and Angular 2’s setup does as well.

My suggestion is to have tns run also setup/run tns livesync by default (and perhaps provide a --no-livesync flag to turn it off or something like that). IMO this would significantly help the getting started experience. One complication is that we probably want https://github.com/NativeScript/nativescript-cli/issues/763 implemented first, so that tns run continues to show console logs and stack traces.

UPDATE (May 20th, 2016): #763 was implemented and shipped in 2.0.

One alternative is that we could include a handful of npm scripts in the default project’s package.json. Something like npm run ios|android that runs the app and sets up a watcher by default. For example in Angular 2 npm start, starts a browser tab and an HTTP server, watches for changes to code, and deploys those changes automatically.

[stephenfeather]

Agree with @tjvantoll, can say I use watchy a good bit around my dev environments, having 2 or 3 terminals open, touching each other to trigger various build stages.

Yes, that watched build, that LiveSync is high on the expectation list for new users. Provided the user's environment can handle it, put up some info in the docs and turn it on.

(Side rant, xCode is the worst with its partial saves of your work as you are typing, triggering off broken process' down stream.)

[sitefinitysteve]

+1 makes sense, one less command to confuse people...

[teobugslayer]

As a work-around, livesync builds and deploys the project if needed.

I.e. instead of run finishing with livesync, livesync starts with run.

Perhaps we can make this more visible in the documentation?

[tjvantoll]

@teobugslayer Ah ok, I didn’t know that. This section of the getting started guide would probably be the place to do that, but I’ve been holding off promoting livesync there because it still hides errors and stack traces.

[burkeholland]

I think that LiveSync should be the default experience for tns run

[tjvantoll]

@valentinstoychev With the livesync improvements coming in 2.1 and 2.2, can we consider making it the default experience as this issue suggests?

[sipacate]

Yup. I fully agree that would be the nicest thing to do from the developer experience.

[sitefinitysteve]

...IMO --watch by default as well, whats the use case for livesync with no watch specified?

[atanasovg]

I support this only given that livesync works as expected. Otherwise we'd need a separate option in the tns run command, purely for the sake of disabling the implicit livesync behavior. I guess writing tns run --nolivesync doesn't seem appealing to anyone here :)

We should also consider this from the VSCode extension perspective. @ivanbuhov @blagoev What do you think guys?

[ivanbuhov]

Currently, the VSCode extension comes with Run on Android/Run on iOS commands which are executing tns run android/ios --device/--emulator under the hood. Ideally, we want to have a limited number of commands (the most useful ones) in the VSCode extension. If we are to agree that livesyncing is more useful/used than running, I find it necessary to expose the livesync functionality in the VSCode extension instead of run. We can possibly have both of them but having too many (similar) commands in the VSCode Command Palette may be confusing and will make it harder to find the command you are looking for.