Angular-cli: ng serve should indicate when startup is complete

[lunchboxer]

Running ng serve on a new install and it does lots of magic and takes some time to do this. The last line output reads "webpack: bundle is now Valid". That's great to know, but adding a message with some finality in the tone would be even more useful. I'm thinking something like:

Your Angular app is now being served at http://0.0.0.0:4200/

[Gelio]

That information is provided right after your run ng serve.
Example log of me running ng serve:

F:\Programowanie\personal\idealizer (master) ([email protected])
λ ng serve
** NG Live Development Server is running on http://localhost:4200. **
7118ms building modules
19ms sealing
1ms optimizing
0ms basic module optimization
65ms module optimization
0ms advanced module optimization
10ms basic chunk optimization
1ms chunk optimization
2ms advanced chunk optimization
1ms module and chunk tree optimization
102ms module reviving
4ms module order optimization
3ms module id optimization
2ms chunk reviving
1ms chunk order optimization
8ms chunk id optimization
50ms hashing
1ms module assets processing
109ms chunk assets processing
2ms additional chunk assets processing
0ms recording
1ms additional asset processing
1446ms chunk asset optimization
1134ms asset optimization
33ms emitting
Hash: 67e32945ed6ea403e944
Version: webpack 2.1.0-beta.22
Time: 10129ms
            Asset       Size  Chunks             Chunk Names
   main.bundle.js    2.83 MB    0, 2  [emitted]  main
 styles.bundle.js    19.2 kB    1, 2  [emitted]  styles
        inline.js    5.53 kB       2  [emitted]  inline
         main.map    2.89 MB    0, 2  [emitted]  main
       styles.map    25.3 kB    1, 2  [emitted]  styles
       inline.map    5.59 kB       2  [emitted]  inline
       index.html  479 bytes          [emitted]
assets/.gitignore    0 bytes          [emitted]
Child html-webpack-plugin for "index.html":
         Asset     Size  Chunks       Chunk Names
    index.html  2.81 kB       0
webpack: bundle is now VALID.

As you can see, there's:

* NG Live Development Server is running on http://localhost:4200. *

[lunchboxer]

That's great. Since no one will ever see that without scrolling all the way back, I am suggesting that it be moved to the very end. This makes it so that people can read info they are likely to go and use as well as giving them a clue that the start-up process is complete. Wouldn't that be a cheap, minor improvement?

[Gelio]

I do not see much benefit in this. You need this information only once in your project because the port or address won't change between consecutive ng serve's. Newcomers also have this information listed in the README.

I've looked at the files and found where this may be.
tasks/serve-webpack.ts:

// ...
    const webpackDevServerConfiguration: IWebpackDevServerConfigurationOptions = {
      contentBase: path.resolve(
        this.project.root,
        `./${CliConfig.fromProject().config.apps[0].root}`
      ),
      historyApiFallback: true,
      stats: webpackDevServerOutputOptions,
      inline: true,
      proxy: proxyConfig
    };

    ui.writeLine(chalk.green(oneLine`
      **
      NG Live Development Server is running on
      http://${commandOptions.host}:${commandOptions.port}.
      **
    `));

    const server = new WebpackDevServer(webpackCompiler, webpackDevServerConfiguration);
    return new Promise((resolve, reject) => {
      server.listen(commandOptions.port, `${commandOptions.host}`, function(err: any, stats: any) {
        if (err) {
          console.error(err.stack || err);
          if (err.details) { console.error(err.details); }
          reject(err.details);
        }
      });
    });
// ...

It's probably the case of moving that ui.writeline inside the promise.

Having said this, we still need to wait for more people to comment on this. Personally, I don't perceive this as necessary.

[jhelbig]

I agree with @lunchboxer. This is information, especially when pertaining to containers, that would be helpful at the end of the long list of build garbage. I could care less about if all my files were installed or optimized correctly. I only care if:

A) something went wrong
B) if the task I set in motion has been completed

Any other back-end framework will always put this at, or close to, the end of the deployment logs. Furthermore, I doubt that I could access the application when the log that says the server is up. What if there was a deployment error, now you're showing the server was up even though it never actually was. This would infuriate me to no end from a debugging view point, "Did my problem begin before the server was fully functional or after?" The answer to that question could open two totally different debug paths.

[gelliott181]

I see this as a non-issue, especially for what amounts to a dev server that shouldn't be used for production. The final output of a new bundle is a Webpack log of the files, without bumping you to the console. That makes it clear to me: If there's a prompt, the server is not running.

[lunchboxer]

Maybe I'm stupid, but it doesn't make it clear to me, nothing in the output says definitively that the start-up is done. That is the feature that I am requesting. Other dev servers like to do it in the way I suggested, but simply, "ok" will also suit my needs.

[gelliott181]

To address the startup part first: The server outputs ** NG Live Development Server is running on http://localhost:4200. ** when it starts. The server only starts once, and when the app updates it does not restart the server.

You are asking for the state of the server when the bundle updates, even though the server never changes state (Calling ng serve starts the server, and doesn't stop it without user interaction, ever.) This is redundant given that you have an "OK" written using a synonym that more accurately describes the state of the app. The literal last line is webpack: bundle is now VALID. which means webpack has successfully built the app and is serving it. When you save something with the server running, webpack writes webpack: bundle is now INVALID., builds the changes, then writes another set of bundle metadata, followed by the line webpack: bundle is now VALID. if it's all good in the hood.

I cannot think of anything more verbose about state changes than clearly defining when the server has come up (The first line, when it actually starts being available for use), and when the bundle you're serving has become valid (The last line after any changes to the app have been successfully built and are available to serve). What's the point of saying the server is up if it can't and won't be taken down mid-process without the user explicitly stopping it? Sounds to me like extra code and extra overhead for no gain.

[jhelbig]

something that is VALID =/= ACTIVE. If anything, the webpack should be validated first before the statement of success that the server is running, nobody would want to run an active server with an invalid webpack.

The original request is asking for is some sort of server status at the end that states if the application is active or not. The validity of the webpack should only be a precursor to the status of the server, not the flag that says everything is "OK".

Furthermore, I'm finding it difficult to find anywhere in the repo where it states the bundle is INVALID. Upon deeper investigation my suspicions of the server not actually being up at the time of the "Server Up" message are true.

https://github.com/angular/angular-cli/blob/master/packages/angular-cli/tasks/serve-webpack.ts#L63-L70

It looks like the log output of the is just spitting out un-validated text to the console stating the server is up, even though there's literally no logic that tests otherwise.

I feel that the responses to this issue are being very dismissive without giving any detail about why it's not a good idea. I am seriously questioning the motives that are behind this, and it concerns me that there may be something more that you are attempting to not discuss.

[gelliott181]

@jhelbig Starting the server and placing the status after the first compilation may make sense, but you're still missing the point that the server never goes down again. It is put up, then just serves and serves until the end of the process. The Webpack Valid/Invalid is entirely separate from the server's ability to serve a web page, and as such the validity of your bundle is the only thing that changes when you save.

Let me repeat: The server is set up once and then Webpack bundles and watches until you tell the server to stop. There is no server startup after the first message. There is no change to the server's state. Nothing. The webpack bundle it spits out? Yeah, constant updates, and that's clearly marked by the bundle validity. This has nothing to do with the server being able to accept and respond to requests.

Furthermore, the state of the application is not the same as the state of the server. The server can still serve a broken application that won't run. It still sends out that index.html. The server state message would tell you that it's serving, but your app would still fail.

[gelliott181]

This comment had a bunch of unnecessary and charged words. I've cleared them out because cooler heads must prevail. Earlier comments are left as is.

[lunchboxer]

I have always understood that the server does not go down. I use "webserver" in the title. It should be clear that I mean the content being served also being fully ready. To avoid confusion I will be more precise in the future. I find is strange that requesting output message that startup is complete is met with such controversy. It seems perfectly normal for a terminal app with spews so much output, and occasionally pauses, that it should tell you when things are fully usable.

[gelliott181]

Alright @lunchboxer that's a lot clearer! I'm not sure if you're aware, but if you refresh the page yourself while watching the webpack bundle ops (After the bundle is marked Invalid) you'll get an output of

webpack: wait until bundle finished: /

This is just tossed out there to stdout while webpack bundles. This is webpack saying "I've received a request for something that isn't ready to serve and am holding the connection until it is." Again though, the content being served is that bundle I keep mentioning, bringing me back to the validity being the indicator for content being ready. If the bundle isn't valid the content won't be served. Anything closer to your app than the webpack bundle emission should be handled by you, as each project has its own criteria for being "started". I also make no claims that webpack bouncing this out to stdout with no cares about what's already printed is useful compared to what you're aiming for, but it's also not in the CLI's scope anymore if I understand the dependency correctly (That's webpack-dev-server territory I believe).

Example: I can build an offline app that's entirely self contained and it would be in a "started" state immediately after being valid. My current project at work? The client starts and loads data, but until it's verified my back end is available and trusted it's not done starting up. Two very different locations to log a startup at.

[jhelbig]

This comment had a bunch of unnecessary and charged words. I've cleared them out because cooler heads must prevail. Earlier comments are left as is.

I personally don't think you said anything that was out of line, in-fact I share in your frustration on other topics not in any relation to this.

Your earlier comment, I get it now. There are times when you will need to restart the server/build process, and it will be assumed that the server will always be up and only the validity of the webpack is what concerns you.

Coming from a background where the status of the server was always the end-all-be-all, it's sometimes difficult to change the thought process that has been ingrained in everything you do for so long.

[gelliott181]

I'm so glad we all came to a good conclusion on this!
@jhelbig I agree that it's hard to see the answer when it's hidden by assumptions from years of now incorrect practices. I had this same mental maze starting with Node because I came in from an Apache/nginx and PHP background. I was reading these comments and getting frustrated because I was seeing my own confusion from years past, and felt at a loss as to why I couldn't explain to you what I just intuit these days. Again, so glad we could get this sorted without anyone leaving feeling like they were wronged.

[lunchboxer]

Thanks all. your comments have helped make this issue easier to understand. My concern is simply that perhaps some user anxiety could be mitigated, by making this prior knowledge less of a prerequisite. To understand why I am so bothered by this, enough to open this issue, it may be important to know that the output quoted above in the response to the initial comment, is relatively concise. That is not the experience that I had. Many users will instead see a terminal with hundreds of lines of output. By the time it finishes the first round of validation the output may have surpassed the limit of the buffer. In my case I was unable to scroll back and see the line indicating that the server was up and running on a certain port, but this is vital information. Personally the server up line I mention is what I am accustomed to seeing with similar tools. That is to say I'm used to seeing that line not only as signal that the server is running and which port to look for it on, but also as the indication that the start-up process is complete. It has been pointed out to me that with ng serve we are actually waiting for webpack to compile and validate. When I ran ng serve for the first time, this was simply not evident to me. I believe that many other users may experience the same confusion, wondering if start-up has in fact completed.

Have I understood correctly that this is an issue that should be address at webpack dev-server repo?

[filipesilva]

These serve logs are created by webpack and at the CLI we're not too bothered by it's default format.

If you disagree with how webpack shows it, please voice your concerns in https://github.com/webpack/webpack.

We also accept PRs to make it more palatable.

[angular-automatic-lock-bot[bot]]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{_This action has been performed automatically by a bot._}