Angular-cli: When is --mobile flag going to be ready

Created on 19 Sep 2016  路  20Comments  路  Source: angular/angular-cli

Please provide us with the following information:

  1. Mac OSX (Yosemite? El Capitan?)
  2. Versions. Please run ng --version. If there's nothing outputted, please run
    in a Terminal: node --version and paste the result here:

angular-cli: 1.0.0-beta.14
node: 6.6.0
os: linux x64


Thanks! We'll be in touch soon.

RFC / discussion / question faq

Most helpful comment

Context: the mobile flag got removed during the transition from a broccoli-based build system to Webpack-based build system a few weeks back. I was on a 6-week-long leave at the time, so I'm not sure all the details of why it was dropped, but I think it was due to Universal not being updated to support Angular 2.0.0 yet. But shout out to @filipesilva and other folks who worked hard to migrate mobile features to the Webpack CLI! The team worked hard to not drop support, but they had a tough choice to make in order to not make users wait for Angular 2.0.0 final support.

When I returned from leave, I'd started adding back the --mobile flag in #2320. But after some time working on it and trying to get tests to pass, I realized that even if I merged that PR, the custom App Shell generation plugin was prone to cause further headaches for maintainers and users of CLI for a couple of reasons.

  1. Rendering the app shell with Universal requires using services and components that can be rendered in Node. The app shell integration with CLI didn't provide helpful errors when compiling, which could leave users confused when things go wrong. We're exploring how we can generally make build-time pre-rendering more user-friendly outside of the CLI.
  2. CLI currently doesn't have an API to add extensions to core behavior, and the current build system isn't very supportive of a feature like Universal pre-rendering. The team working on CLI are planning to support an add-on API in the future, and from what I understand, are also planning to implement a sort of meta build process around Webpack, but don't quote me on that.

To answer the original question, our plan is to re-incorporate the Angular Service Worker plugin into CLI for projects that use the --mobile flag. @alxhub is working hard on this. We're also going to generate the web app manifest and icons as we were doing before. For the time being, the App Shell generation won't be built into the CLI. We're working on exploring ways to make pre-rendering simpler, and will provide updated docs on mobile.angular.io on how to generate App Shell with CLI and with other build tools.

All 20 comments

What? I had no idea it wasn't ready. Running "ng help" shows the flag so I used it. Then npm install wouldn't work. I spend over an hour trying to figure it out. I reran "ng init" without the --mobile flag, and just like that everything worked. VERY frustrating. I had no idea it was the "--mobile" flag causing the trouble.

I just noticed it the README it says it's been disabled. That's not true. It does just enough damage to cause a lot of pain. I am using 1.0.0-beta.15 btw.

Edit: Actually this might have been from running ng init in a project that I had already ran it in and had an npm-shrinkwrap.json file.

+1

Do we have an estimate of when this will be resolved?:

@jeffbcross can you weigh in?

I'm needing to create a progressive angular app and the examples I found uses angular cli with --mobile flag. What's the time frame for --mobile flag? I'm using angular-cli: 1.0.0-beta.17.

Context: the mobile flag got removed during the transition from a broccoli-based build system to Webpack-based build system a few weeks back. I was on a 6-week-long leave at the time, so I'm not sure all the details of why it was dropped, but I think it was due to Universal not being updated to support Angular 2.0.0 yet. But shout out to @filipesilva and other folks who worked hard to migrate mobile features to the Webpack CLI! The team worked hard to not drop support, but they had a tough choice to make in order to not make users wait for Angular 2.0.0 final support.

When I returned from leave, I'd started adding back the --mobile flag in #2320. But after some time working on it and trying to get tests to pass, I realized that even if I merged that PR, the custom App Shell generation plugin was prone to cause further headaches for maintainers and users of CLI for a couple of reasons.

  1. Rendering the app shell with Universal requires using services and components that can be rendered in Node. The app shell integration with CLI didn't provide helpful errors when compiling, which could leave users confused when things go wrong. We're exploring how we can generally make build-time pre-rendering more user-friendly outside of the CLI.
  2. CLI currently doesn't have an API to add extensions to core behavior, and the current build system isn't very supportive of a feature like Universal pre-rendering. The team working on CLI are planning to support an add-on API in the future, and from what I understand, are also planning to implement a sort of meta build process around Webpack, but don't quote me on that.

To answer the original question, our plan is to re-incorporate the Angular Service Worker plugin into CLI for projects that use the --mobile flag. @alxhub is working hard on this. We're also going to generate the web app manifest and icons as we were doing before. For the time being, the App Shell generation won't be built into the CLI. We're working on exploring ways to make pre-rendering simpler, and will provide updated docs on mobile.angular.io on how to generate App Shell with CLI and with other build tools.

Thanks for the update. Anxiously waiting. Thanks for everyone's hard work on Angular2 and Angular CLI.

I'm closing as the question was answered.

any update on when --mobile and progressive app support will be available? Do you guys have an ETA? Thanks.

Dear @filipesilva ,
you have closed all the issues regarding --mobile-flag:

and referenced without giving an answer. We continue to miss the solution. As a cli-user I would appreciate, if you would let the unanswered questions open.

Thank you!

@webia1 there is an answer by @jeffbcross in https://github.com/angular/angular-cli/issues/2228#issuecomment-253053168.

Yes, thank you, I already have read it but mobile-flag is still disabled. As long as the mobile-flag is disabled, at least one of the issues should be open, so that we get some information about the progress. Don't you think so?

I think that the answer in https://github.com/angular/angular-cli/issues/2228#issuecomment-253053168 is pretty explicit:

For the time being, the App Shell generation won't be built into the CLI.

yes, I'am same opinion, the answer in #2228 (comment) is really pretty explicit, but the question is an another-one:

Why do you close unsolved issues?

@webia1 the issue is solved, and the question is answered.

Why should this issue remain open if there is already a definite answer to it? I understand that you would like to have the --mobile functionality back, but for the moment we are not looking at adding it again.

If/when that changes, the issue might be reopened. But there is no purpose to having an open issue for which we are not looking to act upon.

Dear @filipesilva, if you think, that the deactivation of important features (mobile flag, route generation,..) would be the solution, I've nothing more to say :) Nevertheless, thank you for your answer.

For now, mobile.angular.io still rely essentially on angular-cli, and still refer to the --mobile flag. If you are not planning (for now) to add the --mobile functionality back (it's a shame, but I think we can all understand why now), at least we should move all the references to angular-cli in mobile.angular.io to an "archive" section, and update the docs to remove any dependency to the angular-cli. The support of mobile app development is great on Angular 2, giving that it's still young, but this kind of communication "mistakes" is the kind of reason why a big part of the community is still afraid of Angular 2.

@filipesilva comment perhaps you should remove the temporaly from the message. If it is temporaly, you could provide an open ticket showing your intentions of doing it at some point.

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._

Was this page helpful?
0 / 5 - 0 ratings

Related issues

hartjo picture hartjo  路  3Comments

rajjejosefsson picture rajjejosefsson  路  3Comments

donaldallen picture donaldallen  路  3Comments

purushottamjha picture purushottamjha  路  3Comments

NCC1701M picture NCC1701M  路  3Comments