I wouldn't use cordova-cli if I were to develop a plugin. I don't think the workflow is ideal.
On Fri, Aug 30, 2013 at 6:47 AM, Michal Mocny <mmo...@chromium.org> wrote: > I am interpreting your concern in two different ways, so I'll clarify my > assumption and answer both: > > ------------------ > > Interpretation (1): You want to develop a new plugin, and find it hard to > find the right files to track inside a cli created workspace. > > If you want to "develop some feature or plugin", I suggest you do not first > create a project in the cli and try to write your plugin directly inside > there manually. > > Instead, create a new plugin using the plugin dev guide[1] and spec[2], > creating it in a separate folder/repo. It seems we don't have a great > "overview" page about how to create a plugin directory structure. I'll see > about adding that, but for now, just consult another plugin structure, such > as cordova-plugin-device[3]. > > Once you've started writing your plugin, and have at least the bare bones > structure, create a cli project to consume it: > > cordova create App ... && cd App > cordova platform add ... > cordova plugin add PATH_TO_YOUR_LOCAL_PLUGIN > cordova prepare > ... > > Now, every time you make changes to *the original* plugin, you'll need to > re-add it from source: > > cordova plugin add PATH_TO_YOUR_LOCAL_PLUGIN // Doing this should > overwrite the old version > cordova prepare > ... > > Then, Iterate! > > (We may simplify that step with a "plugin upgrade" command one day) > > Note: If you make mistakes in your plugin.xml specifications, the install > may fail and you may end up with a slightly awkward workspace, and will > need to manually delete some files, or just re-create a new workspace for > testing. > > ------------------ > > Interpretation (2): You want to version an entire workspace you've created > with cordova-cli. > > You can do this, but, cli created workspaces have a bunch of "build > artifacts" and it serves little purpose to actually track changes to them > (in my opinion). > > The pieces that are actually worth tracking are the original sources: > platforms, plugins, and your app(s). > > If you would like to manually track versions of platforms or the core > plugins, you are free to clone the git repos manually, and use cordova-cli > to add them from local paths. This way, you can also make downstream > changes inside feature branches etc. > > If you do not actually need to make changes to platforms/plugins, it is > easier to let CLI automatically fetch the latest stable versions for you, > or fetch specific version you request for you, and trust that we will serve > good working versions. You can always revert to older versions if issues > come up. > > Again, you can of course add the whole workspace into a repo and share that > across a team, but much of those files are created as a result of file > munging and will change in odd ways over time. > > ------------------ > > > [1]: > http://cordova.apache.org/docs/en/3.0.0/guide_hybrid_plugins_index.md.html#Plugin%20Development%20Guide > [2]: > http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html#Plugin%20Specification > [3]: https://github.com/apache/cordova-plugin-device > > -Michal > > > > On Fri, Aug 30, 2013 at 5:51 AM, lmnbeyond <lmnbey...@gmail.com> wrote: > >> Hi all, >> >> Cordova was separated into tens of individual repos ever since 3.0 >> and we're benefit from this change and can quickly build/test apps. >> >> For now, if I want to develop some feature or plugin, I can first >> create a project by cli, then did some changes, but meanwhile it's >> difficult to track which files got changed/added/removed, since all source >> was not under source control. And it's also error prone to manually do the >> tracking. The structure of cordova-x repos is different from the structure >> in a development project. >> >> It was easier if there was an all-in-one project, I mean all >> native sources in a single project, before 3.0. >> >> >> Best Regards! >> >> >> >>
