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
Separate Restoring from Preparing #54
base: master
Are you sure you want to change the base?
Conversation
I agree that this has been a horrible source of bugs, and still isn't quite right, but I'm not convinced making this change is necessarily the right thing to do, vs just making the current intended behavior work properly (I'm also not convinced it isn't the right thing to do... still thinking it through). However, I wonder about this scenario:
|
I like the proposal and think it would be a good fit for cordova@7. Expected behavior for npm projects is to run I like the idea of notifying users that they need to run |
Created an issue for tracking purposes. https://issues.apache.org/jira/browse/CB-11981 |
I'm thinking we hold off on this until cordova@8. In cordova@7, during restore, we copy relevant info from config.xml into package.json for saved platforms and plugins. Having users run a |
I would like to resurrect this. Getting back into cordova for several months now, I have been really confused by the restore functionality, and why it was included in prepare. The goal of the
Adding restore functionality to this violates its intended design. I like breaking out restoration functionality into its own command. As a bonus, the command also happens to line up with the expected workflow for npm-based projects (i.e. clone a node project down, We would need to heavily blog / document this new flow, but I think it's a step in the right direction and would fix a lot of the bugs in cordova-lib today. It would also keep the design of cordova-lib/cordova-cli consistent: one module per executable command. |
Absolutely agree. I did some research into the current behavior today, and it is totally not obvious - but could and should be. |
No description provided.