[
https://issues.apache.org/jira/browse/CB-13767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16517598#comment-16517598
]
Darryl Pogue commented on CB-13767:
-----------------------------------
{quote}I think it would help to know what cordova-fetch does, why it’s
necessary, and why the performance is affected vs. how installation was done
before.
{quote}
Previously, cordova didn't use npm as a registry, it used its own registry and
had its own code to handle retrieving packages and resolving dependencies.
We decided years ago to move to using npm, since it didn't require running our
own registry, and so that we could take advantage of all the work being done by
the npm team on their tooling without additional maintenance burden from our
side.
In the short term (aka, the past few years) cordova-lib contained a mix of
ancient cordova-registry code and support for npm packages via an old bundled
version of npm 2. This caused numerous problems for people, because it meant
that cordova projects that were using npm for managing their project got
unpredictable behaviour due to some commands sometimes using npm2 instead of
the system-wide npm version. In particular, it made it totally impossible to
use npm shrinkwrap with a Cordova project, because npm2 is not shrinkwrappable
by newer version of npm.
cordova-fetch made the decision to offload all the dependency fetching,
installing, and caching to the system installed version of npm. We literally
shell out to npm and tell it to install dependencies for us.
The additional challenge for Cordova is that we need to do steps after the
dependency is installed, and we need to do extra verification around the
version of a dependency that is installed because you can't have the same
plugin installed with different versions at different levels of the
node_modules folder. The current released version of cordova-fetch prints out
the list of all installed modules before/after each operation and compares them
to find out what changed. This is very slow, and leads to all sorts of other
hard-to-diagnose errors.
These changes use the version information reported back from the npm command to
determine the version, which is much faster.
The other change here is to check ahead of time if a dependency is already
installed with the version that we need. Unfortunately, this isn't possible to
do with git dependencies.
> Huge performance issues moving from cordova 6.5 to 8 due to cordova-fetch
> -------------------------------------------------------------------------
>
> Key: CB-13767
> URL: https://issues.apache.org/jira/browse/CB-13767
> Project: Apache Cordova
> Issue Type: Improvement
> Components: cordova-lib
> Reporter: Andrew Crites
> Priority: Major
>
> This is for a project with a wide variety of plugins ... about 25. This may
> be above average, but not extreme. I've updated the project from cordova 6.5
> to cordova 8. Cordova 8 always uses {{cordova-fetch}} to install plugins, so
> I can't opt out. Before, I was not using {{cordova-fetch}}.
> {code}
> $ time npx cordova@6.5 platform add ios
> 23.85s user 9.26s system 130% cpu 25.414 total
> $ time npx cordova@8 platform add ios --nosave
> 402.44s user 61.94s system 119% cpu 6:28.09 total
> {code}
> That takes over 15 times longer. {{--nosave}} was used since this is the
> default behavior for 6.5.
> For subsequent installations using {{--save}} (or default) the performance is
> still like this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
