cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: Building cordova.js on first build
Date Fri, 29 May 2015 12:55:17 GMT
+1

On Thu, May 28, 2015 at 6:32 PM, Steven Gill <stevengill97@gmail.com> wrote:

> 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