appium
appium copied to clipboard
chore(appium,support): cache result of check for local appium
This is just a perf improvement. Anecdotally, this shaves 1-to-5 seconds off of an appium driver
or appium plugin
command, depending on system resources (lower end being CI VM's).
While poking around looking for a solution to #16916, I noticed that npm.list()
in @appium/support
was getting called twice. Each call is not fast; an npm
child process must be forked. It ended up being two separate calls to hasAppiumDependency()
. First, we need to resolve the Appium home dir, so we look for appium
in npm ls
output in the directory containing the closest package.json
. Second, Appium's Manifest
class needs to know this information, so it also calls hasAppiumDependency()
which results in another npm ls
. However, that is called with the value of Appium home--not necessarily the same directory as the first call.
It could be argued that the call in Manifest
is actually a bug, since it shouldn't look at Appium home--it should look at the dir of the closest package.json
. However, if the result of hasAppiumDependency(appiumHome)
is true
then this is the same directory. But semantically, it's incorrect. Anyway, it was weird. To avoid all this nonsense, I decided to just determine the answer earlier so we only need to do it once, and hand the result to the Manifest
factory when loading extensions. If it's called again for whatever reason, the result will now be memoized (as will the call to find the closest package.json
).
this needs more time to bake
Current dependencies on/for this PR:
- 2.0
This comment was auto-generated by Graphite.
ok, let us know when it is baked enough for review
This is too out-of-sync