cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Gill <stevengil...@gmail.com>
Subject Re: Building cordova.js on first build
Date Thu, 28 May 2015 22:32:37 GMT
Right now, only the --browserify way does cordova.js generation in the cli.
--browserify is currently designed to work with the CLI. I don't think it
is worth it to add cordova.js generation functionality to the create
scripts for now.

Recently, I added platforms as devDependencies to cordova.js. So we do have
two places where platforms are pinned (platformsConfig.json for cordova-lib
and package.json for cordova.js). Since they are devDependencies, they
aren't double pinned as they won't be installed when cordova-lib uses its
cordova.js dependency.

The platform dependencies for cordova.js are being used when generating
cordova.js (non browserify) for each platform. It grabs the platform
specific code from the dependencies. This generation is usually done when
we are releasing a platform and want to generate a new cordova.js file
which is used in the non-browserify workflow. When using the browserify
workflow, those platform dependencies aren't used as the platform specific
files (exec.js, platform.js) are moved into
CORDOVAPROJECT/platform/PLATFORM/platform_www and are used when building
the browserified cordova.js file.

Since the non-browserify cordova.js is static, we don't actually need to do
runtime generation for that file. I think Murat's usecase is rare and only
will arise for cordova commiters who are changing platform specific js
files. Once a new cordova.js file is generated, might as well commit it to
master for the platform so others get the benefit of the updated js file
instead of waiting for the next release cycle.

Adding a command to coho to streamline this process is probably the way to
go I'm thinking.




On Wed, May 27, 2015 at 7:55 PM, Andrew Grieve <agrieve@chromium.org> wrote:

> Certainly would be nice to have the create scripts generate cordova.js in
> the same way CLI does. Maybe have the create script call into cordova-js?
>
> Would it make sense in this case to have platforms depend on cordova-js,
> rather than the other way around?
>
> Having cordova-js depend on platforms means:
> - we have pinned versions of platforms in cordova-lib
> - we have pinned versions of platforms in cordova-js
> - cordova-lib depends on cordova-js, meaning platforms are double-pinned?
>
> Is it possible that the pinned versions could get out of sync? Seems
> possible...
>
> I think there's probably two ways that we can simplify the dependencies:
> 1. Have platforms depend on cordova-js, and have their create script know
> how to generate a cordova.js
> 2. Have platforms' create script require a --path-to-cordova-js flag.
>
> We could actually do both, since in CLI we don't download package
> dependencies when adding downloading platform packages.
>
> On Tue, May 26, 2015 at 9:14 PM, Murat Sutunc <muratsu@microsoft.com>
> wrote:
>
> > I think this would be a valuable addition to coho.
> >
> > +1
> >
> > -----Original Message-----
> > From: Steven Gill [mailto:stevengill97@gmail.com]
> > Sent: Tuesday, May 26, 2015 5:40 PM
> > To: dev@cordova.apache.org
> > Subject: Re: Building cordova.js on first build
> >
> > npm linking is suggested when testing platform specific JS changes.
> >
> > cordova-coho's prepare-release-branch command will generate cordova.js
> and
> > move it over to the platform, as well as other things, when doing a
> > release. It might be worth breaking out the generating and moving JS part
> > of that step in coho to make that command standalone so platform
> developers
> > could do cordova-coho update-js -r windows to generate + copy cordova.js
> > into cordova-windows (sibling to cordova-coho).
> >
> >
> >
> >
> >
> > On Tue, May 26, 2015 at 5:25 PM, Murat Sutunc <muratsu@microsoft.com>
> > wrote:
> >
> > > Thanks Steven for clarifying this for me.
> > >
> > > For now I'll update the www\cordova.js manually for the windows
> platform.
> > > Windows cordova.js is outdated and I'm hitting a bug.
> > >
> > > Personally, I'm +1 with auto generating cordova.js but it's not as
> > > easy as I originally thought because of the dependencies.
> > >
> > > Currently, updating cordova.js is also not so trivial. We have a
> > > folder structure like this:
> > >
> > > Cordova Project
> > > ├─┬ cordova-js @ Dev (local) Version
> > > │ └── cordova-windows @ NPM Version
> > > └── cordova-windows @ Dev (local) Version
> > >
> > > For platform developers the easiest workflow is to npm-link
> > > cordova-js\cordova-windows to cordova-windows. Once linked you have to
> > > grunt compile cordova-js and manually move file over cordova-windows.
> > >
> > > On second thought, regenerating cordova.js from cordova-cli is not a
> > > great idea. For browserify workflow it makes a lot of sense because we
> > > don't know which plugins the user has but otherwise the file is static.
> > >
> > > -----Original Message-----
> > > From: Steven Gill [mailto:stevengill97@gmail.com]
> > > Sent: Tuesday, May 26, 2015 5:10 PM
> > > To: dev@cordova.apache.org
> > > Subject: Re: Building cordova.js on first build
> > >
> > > If people are into it, I can handle this one as I am very familiar
> > > with the code base since I just did it for the browserify workflow.
> > >
> > > On Tue, May 26, 2015 at 4:15 PM, Steven Gill <stevengill97@gmail.com>
> > > wrote:
> > >
> > > > Hey Murat,
> > > >
> > > > By two files you mean cordova-js-src and www\cordova.js I assume.
> > > > The www\cordova.js file is generated and updated on each release of
> > > > the platform. It will use cordova-js-src to build it when available
> > > > (instead of legacy-exe version)
> > > >
> > > > Problem with removing www\cordova.js and building it on runtime is
> > > > that we loose support of platforms being able to build cordova
> > > > projects independently of cordova-cli. We would have to have
> > > > cordova.js as a dependency for each platform to be able to keep the
> > > > ./bin/create scripts still having access to a cordova.js file.
> > > >
> > > > Right now, the browserify way builds cordova.js at runtime with the
> > > > CLI by grabbing cordova-js-src from platform_www of added platforms
> > > > or from cordovajs/src/legacy-exec if cordova-js-src doesn't exist
> > > > (older
> > > > platforms) . Because of this, we already have cordovajs as a
> > > > dependency of cordova-lib. So theoretically, we could build
> > > > cordova.js at runtime for non-browserify use case using a similar
> > workflow.
> > > >
> > > > I think we should keep the www\cordova.js for now, and add
> > > > non-browserify runtime cordova.js generation behind a flag so we can
> > > > test it out. I see the value in it because we have use cases where
> > > > we update the platform specific JS (in cordova-js-src) but can't
> > > > test without generating a new cordova.js and moving it over to our
> > platforms.
> > > >
> > > > Obviously using the --browserify flag will also work for you to be
> > > > able to test those platform specific changes.
> > > >
> > > > On Tue, May 26, 2015 at 3:31 PM, Murat Sutunc
> > > > <muratsu@microsoft.com>
> > > > wrote:
> > > >
> > > >> Hey there,
> > > >> I've a quick question. Now that every platform comes with
> > > >> cordova-js-src should we remove the www\cordova.js from platform
> > repos?
> > > >> I think it's a better idea to compile cordova.js on first build if
> > > >> it's missing. This way we don't have to update two files when
> > > >> working on platform js.
> > > >> Thoughts?
> > > >>
> > > >> Thanks,
> > > >> Murat
> > > >>
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > For additional commands, e-mail: dev-help@cordova.apache.org
> > >
> > >
> >
>

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