cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: MobileSpec for testing cordova-lib@rc
Date Fri, 09 Jan 2015 15:32:22 GMT
On Thu, Jan 8, 2015 at 8:39 PM, Steven Gill <stevengill97@gmail.com> wrote:

> Just checked out peer-dependencies. Looks like the way to move forward with
> handling our dependency issues.
>
> Right now, plugman publish creates a package.json file by grabbing info
> from plugin.xml. Once published, plugman will automatically delete the
> package.json file. I suggest we stop deleting the package.json file and
> actually commit it to all plugin repos.
>
Sounds good. This way authors can add whatever extra metadata they want.

>
> What is wrong with uploading the plugins with their current ids as package
> names for npm? (ex. org.apache.cordova.device). Then you could just add
> org.apache.cordova.device to your package.json file. It is just for
> distinguishing which modules are plugins at plugin add time? We could do
> that with some sort of check looking for a plugin.xml in the directory or
> maybe adding a cordova plugin keyword to the package.json files. I just
> think uploading them under a different name to npm will get confusing. But
> having a standard that others use as well doesn't sound like a bad idea
> (grunt does it ex grunt-contrib-clean). Worth discussing.
>

I think a prefix will just help for discoverability. E.g. everything that
starts with cordova-plugin- is a cordova plugin.
Is it still important to use reverse-domain-style IDs?
cordova-plugin-org.apache.cordova.file-transfer?
Seems like that's getting a bit verbose, and with the state of our current
"core" apis, I'm not sure we want to might them as promoted /
distinguishable as other random ones.
So maybe cordova-plugin-file-transfer is just fine, and if someone else
write cordova-plugin-file-upload, then that's great!


>
> Ultimately, I'd like to see us support both workflows (CLI vs JS API).
> - We would publish plugins to cordova registry & npm.
>
I believe npm support for multiple registries within one package.json is
coming, but at the same time, I don't think any of us are that interesting
in maintaining our own database... So, +1 for migrating to npm's database.


> - Plugman install would pull down from one (eventually default to npm and
> then cordova registry as backup if not found on npm or if version is lower)
> - Eventually close down the cordova plugins registry, move plugins over to
> npm only. Plugins.cordova.io would just search npm based on a cordova
> plugins keyword (like http://gruntjs.com/plugins)
>
+1

>
> With the JS API workflow, users can write code in es6 and use a transpiler
> (like https://www.npmjs.com/package/6to5)  to convert that code to es5 and
> that is their www code. Then we run the cordova JS API to create a project
> out of that. Have the transpiling + creating cordova project as a build
> step in our package.json (or grunt/gulp). I guess this technique can be
> used to use other modules that support browserify and run that as a build
> step before building the cordova project.
>
> Fun stuff!
>
>
>
>
>
>
>
>
>
> On Thu, Jan 8, 2015 at 3:36 PM, Mark Koudritsky <kamrik@google.com> wrote:
>
> > +1 for publishing plugins to npm
> >
> > We will need to come up with a good naming convention so that translating
> > from plugin id to npm package name would be trivial. Preferably with some
> > stable prefix (like cordova_plugin_) so that it would be easy to
> > distinguish plugins if they are listed with other dependencies in
> > package.json
> >
> > Another problem to solve are the dependencies _between_ plugins. We don't
> > want nested dirs like node_modules/pluginX/node_modules/pluginY or
> multiple
> > version of the same plugin (like it happens for regular npm deps). Maybe
> > npm peer dependencies could be used to solve this
> > http://blog.nodejs.org/2013/02/07/peer-dependencies/
> >
> > For experimenting with this, there is no need to modify cordova-lib. We
> > just need to publish some experimental plugins to npm registry, let npm
> > download them during npm install and then add ./node_modules to
> searchpath.
> > I tried this with platforms in
> > https://github.com/kamrik/CordovaGulpTemplate
> >
> >
> > On Thu, Jan 8, 2015 at 6:02 PM, Steven Gill <stevengill97@gmail.com>
> > wrote:
> >
> > > This is rad! Definitely a great example showing the JS API.
> > >
> > > I am thinking about also starting to publish our plugins to npm and
> add a
> > > flag to plugman install to fetch from npm instead of cordova plugins
> > > registry. Thoughts?
> > >
> > > On Thu, Jan 8, 2015 at 1:09 PM, Mark Koudritsky <kamrik@google.com>
> > wrote:
> > >
> > > > On Thu, Jan 8, 2015 at 3:47 PM, Michal Mocny <mmocny@chromium.org>
> > > wrote:
> > > >
> > > > > If we add node_modules to search path, will we be able to adjust
> > which
> > > > > versions of platforms/plugins it uses just by modifying
> package.json?
> > > > >
> > > > >
> > > > Since platforms can be added by path. You can replace
> > > > platforms = ['android']
> > > > with
> > > > platforms = ['/path/to/local/cordova-android']   // Should work for
> > using
> > > > e.g. cordova-android 4.x
> > > > or
> > > > platforms = ['../node_modules/cordova-android']
> > > >
> > > >
> > > > > Not sure if platforms use search path, or just plugins?  Also not
> > sure
> > > if
> > > > > we can install plugins from our registry using npm proper, but you
> > can
> > > > use
> > > > > the git repos as a workaround if not.
> > > > >
> > > >
> > > > For plugins it's more tricky (other npm repo, different dependency
> > > model).
> > > > Some options are:
> > > >  - use private cordova subsection in package.json and store plugin
> info
> > > > including versions there in whatever format  we want
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message