cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anis KADRI <anis.ka...@gmail.com>
Subject Re: What's your daily workflow for cordova development?
Date Fri, 30 Aug 2013 19:38:19 GMT
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 <mmocny@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 <lmnbeyond@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!
>>
>>
>>
>>

Mime
View raw message