Re: What's your daily workflow for cordova development?

[lmnbeyond <lm...@gmail.com>]

Hi,

   Thanks for all your detailed explanations.  

   I tend to agree with @Anis KADRI, CLI is amazing, but it's a little low-productive to iterate "add/remove".

   However, I think I can accept a compromise: add a "plugin upgrade" command, as @Michal Mocny has mentioned. 



Best Regards!



On 2013-8-31, at 上午5:03, Anis KADRI <an...@gmail.com> wrote:

> Neither CLI nor plugman (at least while developing).
> 
> I would create a project using our platform scripts and develop my
> plugin in that project workspace and when I feel that my plugin is
> ready that I will create a plugin.xml and test it out with plugman and
> CLI and then publish it.
> 
> plugman automates plugin installation but I don't think it adds any
> real benefits to plugin authors.
> CLI automates cross-platform project management but I don't think it
> adds any real benefits for plugin authors either. Unless we're talking
> about javascript only plugins, in which case you just work on your
> www/ folder and test out things with CLI commands. For plugins that
> require native bits you have to re-add it every time since your
> platforms/ folder gets blown away on every build. That is why I said
> it's not ideal.
> 
> That is how I roll but I don't expect or advise anybody to do the same.
> 
> On Fri, Aug 30, 2013 at 1:16 PM, Brian LeRoux <b...@brian.io> wrote:
>> Pls explain.
>> On Aug 30, 2013 12:45 PM, "Anis KADRI" <an...@gmail.com> wrote:
>> 
>>> 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 <mm...@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 <lm...@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!
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>