added cordova8 proposal #72

stevengill · 2017-08-02T23:50:43Z

Some ideas we have for the next major version of cordova. Thoughts?

Let me know what points need discussing in more detail.

dpogue · 2017-08-02T23:58:08Z

To the extent that we're using npm now for managing platforms and plugins, do we actually need a cordova install command or is npm install sufficient? I guess the issue is the step of actually creating the platforms/[whatever] folders?

stevengill · 2017-08-03T00:06:24Z

Removing platforms is a much bigger refactor I think. All the platform create scripts need to output the templates, cordova.js, other build artifacts to some location. We do directly call the create scripts from node_modules/<platform>, but those create scripts then output to the platforms directory. Platforms directory is essentially our dist/build directory. You can get access to generated Xcode/android studio projects. It could be something we look at down the line though.

Just realized I should probably also add moving plugin/platform dependencies out of config.xml and have them only in package.json. Stop the auto syncing of config.xml and package.json. This currently happens during the restore step in cordova prepare.

dpogue · 2017-08-03T00:08:44Z

Yeah, I'm not currently suggesting getting rid of the platforms folder, just wondering if it is created by cordova install or by cordova prepare? If it is created by cordova prepare, do we need cordova install at all?

filmaj · 2017-08-03T01:43:54Z

I am in favour of all of these points. But oof, that seems like a whole lotta work. All for the better, I think!

@dpogue on the topic of install vs. prepare, I'd like to point out that stuffing more of this functionality into prepare is what spurred the discussion in the first place, as per a comment on the install proposal: "I agree that [restore] has been a horrible source of bugs, and still isn't quite right."

@stevengill brought up a good point in that discussion that install feels like the right place to do project-setup type actions, rather than again stuffing into prepare.

Finally, I'd like to point to my comment in that proposal to highlight that we should strive to keep the design of cordova-lib consistent. In order keep the prepare command true to its initial design, we should keep pre-compilation steps encapsulated in prepare (needed due to the abstracted-above-platform-specifics nature of cordova). As @stevengill pointed out, providing an API like install keeps the workflow or setup-specific tasks like pulling in dependencies and creating project configuration separate from prepare's pre-compilation/build tasks.

To your question about whether we can get away with just running npm install: I think encapsulating install/post-install commands in a cordova install comamnd, and mirroring npm in that way, provides us a great stepping stone for eventually automatically running cordova install after an npm install (via npm scripts, for example). Worth exploring that more.

I would suggest any further discussion on the implementation details / specifics of install be debated in #54 instead of here. We can always bring the decisions / suggestions from that discussion back here (where prepare vs. install is only a subset of the larger changes being deliberated).

audreyso · 2017-08-03T13:53:22Z

proposals/cordova8.md

+* Reduce maintenance burden of cordova tooling
+* Refactor cordova-lib 
+* Improve unit test coverage
+


Nice work on the proposal! I really like the idea of adding more unit tests! 👍

audreyso · 2017-08-08T17:51:40Z

proposals/cordova8.md

+
+* Remove deprecated platforms (non platform api compatibile platforms).
+This is just a continuation of what we started in `cordova@7`
+ * **Do Now** deprecate `webos` (in cordova@7)


deprecation notice for webos
https://github.com/apache/cordova-lib/pull/585/files

audreyso · 2017-08-08T17:52:05Z

proposals/cordova8.md

+
+* Remove `cordova platform save` command
+This command isn't necessary anymore since we save by default since `cordova@7`. It was previously used to save added plugins and platforms to `config.xml`. 
+ * **Do Now** add deprecation notice for next `cordova@7` release.


deprecation notice for platform save
https://github.com/apache/cordova-lib/pull/585/files

audreyso · 2017-08-08T17:53:01Z

proposals/cordova8.md

+ * **Do Now** add deprecation notice for next `cordova@7` release.
+ * remove use of `cordovaProject/platforms/platforms.json`
+ * axe `cordova-lib/src/cordova.platform_metadata.js`
+ * issue: https://issues.apache.org/jira/browse/CB-13057


started the work for removing platform save 13057
apache/cordova-lib#586

audreyso · 2017-08-08T17:53:28Z

proposals/cordova8.md

+This is just a continuation of what we started in `cordova@7`
+ * **Do Now** deprecate `webos` (in cordova@7)
+ * Remove `webos`, `bb10`, `ubuntu` + all associated files 
+ * issue: https://issues.apache.org/jira/browse/CB-13056


started 13056 --> apache/cordova-lib#588

shazron · 2017-08-08T21:57:24Z

proposals/cordova8.md

+ * https://issues.apache.org/jira/browse/CB-13059
+
+* Remove `cordova platform save` command
+This command isn't necessary anymore since we save by default since `cordova@7`. It was previously used to save added plugins and platforms to `config.xml`. 


Would users upgrading from a project using an older cordova version still need this, to save their existing platforms and plugins?
If we remove this, they will have to manually add them in config.xml, no?

Looking at the analytics (assuming I'm doing this correctly), the command has been used 64 times out of the past 1.9 Million requests. Less that 0.1 percent. Pretty clear sign that it is not being used much.

I do see the usefulness of the command for users pre 7 who didn't used to use --save (which has been around much longer). I just don't think people in that group are even aware of the platform save command.

I think by this point asking users to modify config.xml or readd plugin + platforms is fair. They will probably have to readd/update older platforms or plugins anyways.

Removing it will clean up cordova-lib a bit and allow us to get rid of these extra generated config files that go into peoples cordova projects

Thanks for digging into the analytics @stevengill. It is clearly not a use case we need to worry about much, which is good, simplifying the path forward!

brodycj · 2018-06-03T18:36:29Z

Should we merge, close, or do something else with this one?

added cordova8 proposal

a828b45

audreyso reviewed Aug 3, 2017

View reviewed changes

stevengill mentioned this pull request Aug 7, 2017

Better integrate with module bundlers #73

Open

audreyso reviewed Aug 8, 2017

View reviewed changes

shazron reviewed Aug 8, 2017

View reviewed changes

dpogue added the cordova-8 label Jul 24, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

added cordova8 proposal #72

added cordova8 proposal #72

stevengill commented Aug 2, 2017

dpogue commented Aug 2, 2017

stevengill commented Aug 3, 2017

dpogue commented Aug 3, 2017

filmaj commented Aug 3, 2017

audreyso Aug 3, 2017

audreyso Aug 8, 2017

audreyso Aug 8, 2017

audreyso Aug 8, 2017

audreyso Aug 8, 2017

shazron Aug 8, 2017

stevengill Aug 8, 2017

filmaj Aug 9, 2017

brodycj commented Jun 3, 2018

added cordova8 proposal #72

Are you sure you want to change the base?

added cordova8 proposal #72

Conversation

stevengill commented Aug 2, 2017

dpogue commented Aug 2, 2017

stevengill commented Aug 3, 2017

dpogue commented Aug 3, 2017

filmaj commented Aug 3, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

brodycj commented Jun 3, 2018