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, 11 Jun 2015 03:27:15 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message