cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: What's your daily workflow for cordova development?
Date Fri, 30 Aug 2013 13:47:30 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message