cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nikhil Khandelwal <nikhi...@microsoft.com>
Subject RE: Building cordova.js on first build
Date Wed, 10 Jun 2015 16:19:50 GMT
From what I understand, the grunt:compile option and generation of cordova.js is part of a
committer-only workflow when an update to cordova.js is made and a platform specific cordova.js
file needs to be updated in the platform repo. Use of devdependencies in npm using verion
numbers almost always does the incorrect thing as it ends up getting the _released_ version
of the platform and generates the cordova.js. I understand that this can be worked around
by doing npm link to the platform repos, but that's only a workaround and not easy to discover
or understand. 

There are other ways to do this, by having grunt:compile explicitly taking the location of
the platform repo. As a default, it could also 'assume' a folder structure and look for the
corresponding platform repo. Alternatively, the devdependencies can be relative folder links
as opposed to version-specific links. Having to update pinned versions at two places is error
prone and easy to miss. For example, currently for the windows platform we are pulling   
"cordova-windows": "3.8.x" - even though 4.0.0 is already out there.

Thanks,
Nikhil


-----Original Message-----
From: brian.leroux@gmail.com [mailto:brian.leroux@gmail.com] On Behalf Of Brian LeRoux
Sent: Friday, May 29, 2015 5:55 AM
To: dev@cordova.apache.org
Subject: Re: Building cordova.js on first build

+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
> > > >
> > > >
> > >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Mime
View raw message