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 Thu, 11 Jun 2015 17:08:31 GMT
Thanks for making this change. I know createmobilspec (and in turn the Buildbot CI) depends
on this as it attempts to create the latest cordova.js. After this change it will generate
the latest cordova.js (instead of the released one) for testing purposes which IMO is the
correct default behavior.

Enhancing the readme to include how a committer should make a cordova.js change would also
be super useful. 

Thanks,
Nikhil


-----Original Message-----
From: Steven Gill [mailto:stevengill97@gmail.com] 
Sent: Wednesday, June 10, 2015 8:27 PM
To: dev@cordova.apache.org
Subject: Re: Building cordova.js on first build

PR: https://github.com/apache/cordova-js/pull/117

On Wed, Jun 10, 2015 at 12:30 PM, Steven Gill <stevengill97@gmail.com>
wrote:

> Yes, this seems to be a chicken and egg problem.
>
> My original thought was to make cordova.js standalone. I didn't want 
> to require a certain directory structure to build cordova.js or force 
> developers to pass in a path to a platform (especially when building 
> multiple platform's JS).
>
> But I see your point about it being always behind a version when 
> cutting a release. Can't update devDependency version until platform 
> is released, but need to generate cordova.js and copy it over into 
> platform before releasing. To generate, we require the latest 
> cordova-js-src directory (instead of the previously released version).
>
> I am going to update cordova.js. Remove devdependencies and instead 
> assume platforms as sibling directories to cordova.js as default, but 
> also allow a path to be passed in.
>
>
>
> On Wed, Jun 10, 2015 at 9:19 AM, Nikhil Khandelwal 
> <nikhilkh@microsoft.com
> > wrote:
>
>> 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