Re: [DISCUSS] non-global Cordova installs

[Dmitry Blotsky <dm...@gmail.com>]

No, they're not the same. The difference is significant in the case of a typo.

$ ./node_modules/.bin/cordov
-bash: ./node_modules/.bin/cordov: No such file or directory

$ npx run cordov
Whoops! Someone's uploaded your home directory to their website. I hope it had nothing important!

NPX introduces this failure mode at every Cordova invocation, something that eventually happens habitually.

Dmitry

> On May 27, 2019, at 7:10 PM, Jesse <pu...@gmail.com> wrote:
> 
> After an ‘npm install cordova’ all ‘npx cordova ..’ ARE calls to node_modules/cordova ...
> 
>> On May 27, 2019, at 5:01 PM, Dmitry Blotsky <dm...@gmail.com> wrote:
>> 
>> Even if we agree to use NPX for the initial Cordova run, using it in every call instead of "./node_modules/.bin/cordova" introduces major failure modes.
>> 
>> Dmitry
>> 
>>> On May 15, 2019, at 11:32 PM, Jesse <pu...@gmail.com> wrote:
>>> 
>>> I think there is a disconnect on the actual proposal here.
>>> 
>>> Here's the pr again ( keep the discussion here please )
>>> https://github.com/apache/cordova-docs/pull/987/files
>>> 
>>> The only real use of npx as a one-off command would be the call to create a
>>> new app. ie. `npx cordova create dirname ...`
>>> The instructions after that are to cd into the dir, and install cordova
>>> locally.
>>> All npx calls after that are run from inside a project folder and are just
>>> the same as npm run commands, they access the binary exported in
>>> node_modules/cordova
>>> 
>>> That said, I do still think npx should be presented as an alternative, and
>>> not necessarily the 'preferred' way.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Wed, May 15, 2019 at 10:38 PM Dmitry Blotsky <dm...@gmail.com>
>>> wrote:
>>> 
>>>> In terms of exposure, btw, npx is indeed strictly worse than npm install.
>>>> It checks for dependencies, installs them, and runs them: all at every call
>>>> of a command. That is more frequent than how often anyone runs npm install,
>>>> and is more overhead than running a shell command directly.
>>>> 
>>>> From a higher-up perspective though: every other software ecosystem gets
>>>> by with just running commands in a shell. How is our situation so
>>>> outlandish that the most time-tested tools don’t meet our command-running
>>>> needs?
>>>> 
>>>> Dmitry
>>>> 
>>>>> On May 15, 2019, at 22:29, Dmitry Blotsky <dm...@gmail.com>
>>>> wrote:
>>>>> 
>>>>> If it’s any convincing data: none of React Native, Ionic, Angular,
>>>> Ember, Meteor, or Vue mention npx.
>>>>> 
>>>>> They all recommend npm install -g or some variant using more mature
>>>> tools.
>>>>> 
>>>>> I agree that it would be a piece of cake for us to instruct people to
>>>> install cordova for the local user, or to use per-project installs of
>>>> cordova. These options are all still pretty convenient, and don’t incur the
>>>> security penalties of npx.
>>>>> 
>>>>> Dmitry
>>>>> 
>>>>>> On May 15, 2019, at 02:15, Jesse <pu...@gmail.com> wrote:
>>>>>> 
>>>>>> Given how contentious this has become, I think our best approach would
>>>> be
>>>>>> to continue with our global install expectation, and add documentation
>>>> on
>>>>>> a) what to do if you have issues with `npm i -g cordova` [1]
>>>>>> b) document how to do local dependencies and use npx ( this might be a
>>>> good
>>>>>> blog post as well as permanent documentation )
>>>>>> 
>>>>>> Regarding some of the issues stated previously:
>>>>>> 
>>>>>>>> Dmitry: 1. It is strictly less secure than the status quo, and all
>>>>>> alternatives. ..
>>>>>> The exposure to the user is no different than `npm install -g`, it is
>>>> just
>>>>>> harder to know exactly what is happening.
>>>>>> 
>>>>>>>> Dmitry: 2. It is strictly less stable than a local installation ...
>>>>>> Only the first `npx cordova create ...` will result in a fetch, further
>>>>>> uses of npx cordova will use the cached version, and can be done
>>>> without a
>>>>>> network connection.
>>>>>> 
>>>>>>>> Darryl: Encouraging people to install Cordova globally causes issues
>>>>>> when working on multiple projects ...
>>>>>> Do we have a way of knowing how often this occurs? It sounds rare to me.
>>>>>> Regardless, there is no reason they can't go ahead install
>>>> cordova@version
>>>>>> as a dev dependency
>>>>>> 
>>>>>> Personally, having read up on npx and done some basic tests, I am okay
>>>> with
>>>>>> it.  However, I also don't feel we have to force it on everyone.
>>>>>> We can suggest is as an alternative, and perhaps after we are all more
>>>>>> comfortable with it, it can become the default.
>>>>>> 
>>>>>> 
>>>>>> [1]
>>>>>> 
>>>> https://docs.npmjs.com/resolving-eacces-permissions-errors-when-installing-packages-globally
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Tue, May 14, 2019 at 8:12 PM gandhi rajan <ga...@gmail.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> Hi Dmitry,
>>>>>>> 
>>>>>>> I second you on this.
>>>>>>> 
>>>>>>>> On Tuesday, May 14, 2019, Dmitry Blotsky <dm...@gmail.com>
>>>> wrote:
>>>>>>>> 
>>>>>>>> I'm really glad this discussion lit up, because it clearly shows that
>>>>>>> this
>>>>>>>> issue isn't settled.
>>>>>>>> 
>>>>>>>> I personally have few opinions about the "best" solution here, but I
>>>>>>>> firmly believe that npx is a non-starter for these 2 reasons:
>>>>>>>> 1. It is strictly less secure than the status quo, and all
>>>> alternatives.
>>>>>>>> It is literally downloading code from hundreds of untrusted parties
>>>> and
>>>>>>>> immediately running it. It's worse than piping a curl command into
>>>> bash
>>>>>>> (at
>>>>>>>> least you can check the curl command's URL, or checksum the downloaded
>>>>>>>> script).
>>>>>>>> 2. It is strictly less stable than a local installation because now
>>>> every
>>>>>>>> call to Cordova goes through an opaque dependency.
>>>>>>>> 
>>>>>>>> Unless both of those can be addressed, I think we shouldn't consider
>>>> npx.
>>>>>>>> 
>>>>>>>> Dmitry
>>>>>>>> 
>>>>>>>>> On May 10, 2019, at 4:31 PM, Oliver Salzburg <
>>>>>>> oliver.salzburg@gmail.com>
>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> Our DX is not good and this proposal would have the potential to
>>>> have a
>>>>>>>>> positive impact on that. I'm sorry that you're not convinced yet.
>>>>>>>>> 
>>>>>>>>> Because I don't want to skip back and forth between GitHub and the
>>>>>>>>> mailing list, I'll address your points here.
>>>>>>>>> 
>>>>>>>>> - When you start a new project, unless you create a new cordova
>>>> project
>>>>>>>>> every week, you'll download cordova. npx will only help you in
>>>>>>>>> downloading the package and if you have downloaded it in the past, it
>>>>>>>>> will be pulled from the cache.
>>>>>>>>> 
>>>>>>>>> - Yes, the Cordova CLI behavior can change over time, which is
>>>> exactly
>>>>>>>>> why you would not want to share a single global version with all of
>>>>>>> your
>>>>>>>>> projects. I consider this a pro-local point.
>>>>>>>>> 
>>>>>>>>> - It is 4 more characters to type. Yes. I give you that. But if you
>>>>>>> want
>>>>>>>>> to interact with a local installation of cordova, what exactly is the
>>>>>>>>> alternative? Not installing locally? I disagree.
>>>>>>>>> 
>>>>>>>>> - Your suggestion regarding writing a completely new module to
>>>> initiate
>>>>>>>>> a cordova project is completely besides the point here. If you had
>>>> that
>>>>>>>>> module, you'd still want to use it with npx. And using `npx cordova`
>>>>>>>>> pulls cordova into the cache where you are going to want to have it
>>>>>>>>> anyway. If you had a slimmed down module, you now still need to
>>>>>>> download
>>>>>>>>> cordova.
>>>>>>>>> 
>>>>>>>>> By using npx, given your usage examples, you would have less
>>>> downloads
>>>>>>>>> instead of more.
>>>>>>>>> 
>>>>>>>>> I'm sorry, Brody, I don't see your points and I don't feel like they
>>>>>>>>> have been weighed appropriately against the benefits I proposed
>>>>>>> earlier.
>>>>>>>>> 
>>>>>>>>> I would also appreciate it if we could try to keep the conversation
>>>> to
>>>>>>> a
>>>>>>>>> single media. The split between mailing list and GitHub is not
>>>>>>>> constructive.
>>>>>>>>> 
>>>>>>>>> Almost like putting part of your application in a global context and
>>>>>>>>> another part in a local context is not constructive...
>>>>>>>>> 
>>>>>>>>>> On 2019-05-10 23:08, Chris Brody wrote:
>>>>>>>>>> I am very sorry to say that I am still not convinced about this
>>>> idea.
>>>>>>>>>> I just raised some concerns in a recent comment in:
>>>>>>>>>> https://github.com/apache/cordova-docs/issues/838
>>>>>>>>>> 
>>>>>>>>>> And I think I am not the only one right now.
>>>>>>>>>> 
>>>>>>>>>> As I said in cordova-docs#838, I would favor that we mention using
>>>>>>>>>> `npx cordova` *as an option* in a limited number of places.
>>>>>>>>>> 
>>>>>>>>>> I would like to express my appreciation to Oliver for the time and
>>>>>>>>>> effort has given to improve the documentation, and to contribute a
>>>>>>>>>> number of updates and fixes in the past. But I would rather take the
>>>>>>>>>> extra time and effort to ensure we keep up the best app DX we can.
>>>>>>>>>> 
>>>>>>>>>> And I don't really follow what you mean about CORDOVA_CMDLINE, would
>>>>>>>>>> probably be easiest if we keep it in a separate discussion thread or
>>>>>>>>>> issue.
>>>>>>>>>> 
>>>>>>>>>> On Fri, May 10, 2019 at 3:05 PM Oliver Salzburg
>>>>>>>>>> <ol...@gmail.com> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> I have already started working on a PR to make the necessary
>>>> changes
>>>>>>> to
>>>>>>>>>>> the documentation, as I was under the impression that consensus
>>>>>>>>>>> regarding this issue was already reached:
>>>>>>>>>>> 
>>>>>>>>>>> https://github.com/apache/cordova-docs/pull/987
>>>>>>>>>>> 
>>>>>>>>>>> Specifically this might be of interest:
>>>>>>>>>>> 
>>>>>>>>>>> https://github.com/apache/cordova-docs/blob/
>>>>>>>> 04363c2796199f5379fa2b5f000099ac8b1a488a/www/docs/en/dev/
>>>>>>>> guide/cli/index.md
>>>>>>>>>>> 
>>>>>>>>>>> I believe installing the cordova dependency as a devDependency
>>>> should
>>>>>>>> be
>>>>>>>>>>> part of the "create" task. I was planning to propose the necessary
>>>>>>>>>>> changes in another PR, but the freshly ignited debate caused me to
>>>>>>> hold
>>>>>>>>>>> on that.
>>>>>>>>>>> 
>>>>>>>>>>> I also brought up another area of concern regarding CORDOVA_CMDLINE
>>>>>>> in
>>>>>>>>>>> hooks. I mentioned this in the PR.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> On 2019-05-10 20:42, Jesse wrote:
>>>>>>>>>>>> Also thanks for the comprehensive write-up Oliver!
>>>>>>>>>>>> 
>>>>>>>>>>>> Yeah, I am good with a move to recommend npx.
>>>>>>>>>>>> I just ran thru the steps and everything seems to work fine with
>>>> it.
>>>>>>>>>>>> 
>>>>>>>>>>>> One other reservation I had was just about network usage, and
>>>> being
>>>>>>>>>>>> sensitive to places where bandwidth during the day is extremely
>>>>>>>> costly.  I
>>>>>>>>>>>> verified that having previously installed platforms android+ios in
>>>>>>>> other
>>>>>>>>>>>> projects, I was able to `npx cordova platform add android` with
>>>> the
>>>>>>>> network
>>>>>>>>>>>> off and it used a cached version.
>>>>>>>>>>>> 
>>>>>>>>>>>> Are our new getting started steps going to be this ?:
>>>>>>>>>>>> ```
>>>>>>>>>>>> npx cordova create myNewCordovaApp
>>>>>>>>>>>> cd myNewCordovaApp
>>>>>>>>>>>> npm i cordova --save-dev
>>>>>>>>>>>> npx cordova platform add android
>>>>>>>>>>>> npx cordova run android
>>>>>>>>>>>> ```
>>>>>>>>>>>> 
>>>>>>>>>>>> I believe we may also find some issues around cordova-lib having
>>>>>>>>>>>> expectations of number of args and how it outputs some error
>>>>>>>> messages, but
>>>>>>>>>>>> hopefully tests will reveal those.
>>>>>>>>>>>> 
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Jesse
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>> On Fri, May 10, 2019 at 2:46 AM <ra...@gmail.com> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Thanks for that structured write-up, Oliver. You saved me from
>>>>>>>> writing all
>>>>>>>>>>>>> of that myself.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> +100 on all those points
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Oliver Salzburg <ol...@gmail.com> schrieb am Fr., 10.
>>>>>>> Mai
>>>>>>>> 2019,
>>>>>>>>>>>>> 11:01:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I don't see how third-party tools like nvm or nvm-windows play a
>>>>>>>> role in
>>>>>>>>>>>>>> this. If those tools have defects, so be it, but that shouldn't
>>>>>>>> steer a
>>>>>>>>>>>>>> decision when the tools in question ship with the official tools
>>>>>>>> that we
>>>>>>>>>>>>>> use (NodeJS).
>>>>>>>>>>>>>> This holds especially true if the issues have already been
>>>> fixed.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> That being said, it seems like part of this discussion is
>>>> already
>>>>>>>> going
>>>>>>>>>>>>>> into a direction of local vs. global Cordova install, which I
>>>>>>> didn't
>>>>>>>>>>>>>> even think was up for debate anymore. What was up for debate
>>>> last
>>>>>>>> night,
>>>>>>>>>>>>>> was how to interact with local Cordova installs.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> However, let me reiterate all points regarding the entire issue:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 1. A global Cordova installation is a huge issue in itself, as
>>>>>>>>>>>>>> components in Cordova interact with each other in a way that
>>>>>>>> sometimes
>>>>>>>>>>>>>> the global components are used and sometimes the local
>>>> components.
>>>>>>>> This
>>>>>>>>>>>>>> happens during runs of individual tasks, like "prepare", where
>>>>>>> both
>>>>>>>> the
>>>>>>>>>>>>>> local and the global cordova-common are loaded for example.
>>>>>>>>>>>>>> This issue would easily be avoided by placing Cordova itself
>>>>>>>> locally in
>>>>>>>>>>>>>> the project. It allows a per-project Cordova version, which is
>>>>>>>>>>>>>> controlled through the package.json, like any other Cordova
>>>>>>>> component.
>>>>>>>>>>>>>> Having your core component global is a horrible design and many
>>>>>>>> other
>>>>>>>>>>>>>> projects have already realized this years ago and adjusted
>>>>>>>> accordingly.
>>>>>>>>>>>>>> Think gulp-cli, babel-cli, ...
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> The current approach leads to extremely hard to debug issues
>>>> and,
>>>>>>>>>>>>>> ultimately, developer frustration.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 2. Interacting with a local dependency that has a binary
>>>>>>> entrypoint
>>>>>>>> in
>>>>>>>>>>>>>> node_modules/.bin is exactly what npx was made for. It is
>>>> already
>>>>>>>>>>>>>> established as a tool in the NodeJS world and many other
>>>> projects
>>>>>>>> make
>>>>>>>>>>>>>> use of it in the manner we're suggesting.
>>>>>>>>>>>>>> https://reactjs.org/docs/create-a-new-react-app.html
>>>>>>>>>>>>>> https://babeljs.io/docs/en/babel-cli
>>>>>>>>>>>>>> https://gulpjs.com/docs/en/getting-started/quick-start
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> There needs to be a very good reason to avoid adapting a well
>>>>>>>>>>>>>> established approach in the environment you're working in. I'll
>>>>>>> get
>>>>>>>> to
>>>>>>>>>>>>>> that.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 3. Suggesting npx as a way to interact with the Cordova CLI not
>>>>>>> only
>>>>>>>>>>>>>> serves the purpose of invoking the node_module/.bin entrypoint,
>>>>>>> but
>>>>>>>> it
>>>>>>>>>>>>>> will also already work to create a new project when cordova
>>>> isn't
>>>>>>>> even
>>>>>>>>>>>>>> installed. This reduces the barrier of entry and establishes a
>>>> way
>>>>>>>> to
>>>>>>>>>>>>>> interact with Cordova that will always work.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> It is extremely convenient and developers want convenience. If
>>>>>>>> there is
>>>>>>>>>>>>>> one thing we don't need in Cordova, then it is to overcomplicate
>>>>>>>> things,
>>>>>>>>>>>>>> frustrate developers and drive them away.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 4. That being said, convenience comes at a price and Dmitry has
>>>>>>>> outlined
>>>>>>>>>>>>>> the issues that come with npx very well last night on Slack. I
>>>>>>> agree
>>>>>>>>>>>>>> with his points and they are also my own, but I feel the
>>>> benefits
>>>>>>>>>>>>>> massively outweigh these risks.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> npx downloads packages that aren't available locally and
>>>> executes
>>>>>>>> them.
>>>>>>>>>>>>>> This is by-design and a feature I mentioned earlier. It also
>>>> opens
>>>>>>>> the
>>>>>>>>>>>>>> door for a myriad of security issues, as it has the potential to
>>>>>>> run
>>>>>>>>>>>>>> unwanted code with every single execution of `npx cordova`.
>>>>>>>>>>>>>> You just have to type `npx cordoa` once, and suddenly you get a
>>>>>>>>>>>>>> typosquatted package from someone that sends off local data to
>>>> the
>>>>>>>>>>>>>> cloud. As a matter of fact, I published the package "rebecca"
>>>>>>> years
>>>>>>>> ago
>>>>>>>>>>>>>> to illustrate exactly this point. Try `npx rebecca` to see what
>>>> I
>>>>>>>> mean.
>>>>>>>>>>>>>> While you can run npx with --no-install to avoid this, this
>>>> would
>>>>>>>> ruin
>>>>>>>>>>>>>> any convenience we're trying to establish here.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> npx also adds another layer of complexity. You need an
>>>> additional
>>>>>>>> Node
>>>>>>>>>>>>>> process to even locate the entrypoint you want to invoke, check
>>>> if
>>>>>>>>>>>>>> downloads need to be made and so on. This would happen every
>>>>>>> single
>>>>>>>> time
>>>>>>>>>>>>>> you invoke the Cordova CLI. I consider this a minor issue, but
>>>> it
>>>>>>>> is an
>>>>>>>>>>>>>> issue nonetheless.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> With those points in mind, nobody is forced to use Cordova in
>>>> the
>>>>>>>> way we
>>>>>>>>>>>>>> suggest in the docs. I can already install Cordova locally and
>>>> use
>>>>>>>> it
>>>>>>>>>>>>>> with npx if I want to. Users who prefer a global installation of
>>>>>>>> Cordova
>>>>>>>>>>>>>> to avoid the above mentioned issues, are still free to do so and
>>>>>>>> they
>>>>>>>>>>>>>> should find instructions on how to set that up in the
>>>>>>> documentation.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> This is about suggesting to users a way to get started with
>>>>>>> Cordova
>>>>>>>> with
>>>>>>>>>>>>>> as little friction as possible and npx achieves this extremely
>>>>>>> well
>>>>>>>> and
>>>>>>>>>>>>>> leaves us with a far better project structure by default.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On 10/05/2019 10:06, Jan Piotrowski wrote:
>>>>>>>>>>>>>>> While that is correct, nvm-windows indeed had problems with npx
>>>>>>> not
>>>>>>>>>>>>>>> working after it was first added to node - so Julio's was
>>>> indeed
>>>>>>>> true
>>>>>>>>>>>>>>> in the past.
>>>>>>>>>>>>>>> Luckily it was fixed, so even we lowly Windows users now can
>>>> use
>>>>>>>> npx.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Am Fr., 10. Mai 2019 um 09:48 Uhr schrieb Oliver Salzburg
>>>>>>>>>>>>>>> <ol...@gmail.com>:
>>>>>>>>>>>>>>>> npx ships with Node.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On Fri, May 10, 2019, 00:33 Jesse <pu...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Hello Dmitry,
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> In my mind, cordova-cli is intended to be installed globally,
>>>>>>> in
>>>>>>>>>>>>>> situations
>>>>>>>>>>>>>>>>> where that is not is possible we could *maybe* recommend that
>>>>>>>> users
>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>> npx, but I don't think it's a great experience.  btw, npx
>>>> needs
>>>>>>>> to be
>>>>>>>>>>>>>>>>> globally installed ... so ok!?
>>>>>>>>>>>>>>>>> This is really just a symptom of a bad node setup, and would
>>>>>>>> never
>>>>>>>>>>>>>> happen
>>>>>>>>>>>>>>>>> if using nvm or similar node switcher.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> The issue raised in that thread appears to be simply related
>>>> to
>>>>>>>> where
>>>>>>>>>>>>>>>>> config stores its data, specifically opt in/out of telemetry.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On Thu, May 9, 2019 at 2:45 PM Dmitry Blotsky <
>>>>>>>>>>>>>> dmitry.blotsky@gmail.com>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> It’s been a while. :) I hope you’re all doing well.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> I’m writing to start some mailing list discussion about this
>>>>>>>> GitHub
>>>>>>>>>>>>>>>>> issue:
>>>>>>>>>>>>>>>>>> https://github.com/apache/cordova-docs/issues/838.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Please say if we should continue talking there, and we can
>>>> do
>>>>>>>> that
>>>>>>>>>>>>>>>>> instead.
>>>>>>>>>>>>>>>>>> If not, let’s continue here.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> It sounds like we’ve got a request to run Cordova without a
>>>>>>>> global
>>>>>>>>>>>>>> sudo
>>>>>>>>>>>>>>>>>> install. What are the ways you all can think of to achieve
>>>>>>> this?
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Dmitry
>>>>>>>>>>>>>>> ------------------------------------------------------------
>>>>>>>> ---------
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>> ---------------------------------------------------------------------
>>>>>>>>>>> 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
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@cordova.apache.org
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Regards,
>>>>>>> Gandhi
>>>>>>> 
>>>>>>> "The best way to find urself is to lose urself in the service of others
>>>>>>> !!!"
>>>>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> 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
>