New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When is --mobile flag going to be ready #2228

Closed
mwaaas opened this Issue Sep 19, 2016 · 19 comments

Comments

Projects
None yet
10 participants
@mwaaas

mwaaas commented Sep 19, 2016

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.

@caseyhoward

This comment has been minimized.

Show comment
Hide comment
@caseyhoward

caseyhoward Sep 21, 2016

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.

caseyhoward commented Sep 21, 2016

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.

@franciscocabral

This comment has been minimized.

Show comment
Hide comment
@franciscocabral

franciscocabral Sep 28, 2016

Contributor

+1

Contributor

franciscocabral commented Sep 28, 2016

+1

@pietergreyling

This comment has been minimized.

Show comment
Hide comment
@pietergreyling

pietergreyling Sep 30, 2016

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

pietergreyling commented Sep 30, 2016

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

@filipesilva

This comment has been minimized.

Show comment
Hide comment
@filipesilva

filipesilva Oct 8, 2016

Member

@jeffbcross can you weigh in?

Member

filipesilva commented Oct 8, 2016

@jeffbcross can you weigh in?

@SolutiaConsulting

This comment has been minimized.

Show comment
Hide comment
@SolutiaConsulting

SolutiaConsulting Oct 11, 2016

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.

SolutiaConsulting commented Oct 11, 2016

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.

@jeffbcross

This comment has been minimized.

Show comment
Hide comment
@jeffbcross

jeffbcross Oct 11, 2016

Contributor

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.

Contributor

jeffbcross commented Oct 11, 2016

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.

@SolutiaConsulting

This comment has been minimized.

Show comment
Hide comment
@SolutiaConsulting

SolutiaConsulting Oct 11, 2016

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

SolutiaConsulting commented Oct 11, 2016

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

@filipesilva

This comment has been minimized.

Show comment
Hide comment
@filipesilva

filipesilva Oct 14, 2016

Member

I'm closing as the question was answered.

Member

filipesilva commented Oct 14, 2016

I'm closing as the question was answered.

@webia1

This comment has been minimized.

Show comment
Hide comment
@webia1

webia1 commented Nov 4, 2016

@SolutiaConsulting

This comment has been minimized.

Show comment
Hide comment
@SolutiaConsulting

SolutiaConsulting Nov 9, 2016

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

SolutiaConsulting commented Nov 9, 2016

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

@webia1

This comment has been minimized.

Show comment
Hide comment
@webia1

webia1 Nov 23, 2016

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 commented Nov 23, 2016

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!

@filipesilva

This comment has been minimized.

Show comment
Hide comment
@filipesilva

filipesilva Nov 23, 2016

Member

@webia1 there is an answer by @jeffbcross in #2228 (comment).

Member

filipesilva commented Nov 23, 2016

@webia1 there is an answer by @jeffbcross in #2228 (comment).

@webia1

This comment has been minimized.

Show comment
Hide comment
@webia1

webia1 Nov 23, 2016

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?

webia1 commented Nov 23, 2016

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?

@filipesilva

This comment has been minimized.

Show comment
Hide comment
@filipesilva

filipesilva Nov 23, 2016

Member

I think that the answer in #2228 (comment) is pretty explicit:

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

Member

filipesilva commented Nov 23, 2016

I think that the answer in #2228 (comment) is pretty explicit:

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

@webia1

This comment has been minimized.

Show comment
Hide comment
@webia1

webia1 Nov 26, 2016

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 commented Nov 26, 2016

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?

@filipesilva

This comment has been minimized.

Show comment
Hide comment
@filipesilva

filipesilva Nov 26, 2016

Member

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

Member

filipesilva commented Nov 26, 2016

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

@webia1

This comment has been minimized.

Show comment
Hide comment
@webia1

webia1 Nov 26, 2016

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.

webia1 commented Nov 26, 2016

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.

@noelmace

This comment has been minimized.

Show comment
Hide comment
@noelmace

noelmace Dec 1, 2016

Contributor

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.

Contributor

noelmace commented Dec 1, 2016

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.

@sebastianovide

This comment has been minimized.

Show comment
Hide comment
@sebastianovide

sebastianovide Jan 6, 2017

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

sebastianovide commented Jan 6, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment