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 <gandhiraja...@gmail.com>
wrote:

> Hi Dmitry,
>
> I second you on this.
>
> On Tuesday, May 14, 2019, Dmitry Blotsky <dmitry.blot...@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.salzb...@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
> > >> <oliver.salzb...@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 <raphine...@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 <oliver.salzb...@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
> > >>>>>>> <oliver.salzb...@gmail.com>:
> > >>>>>>>> npx ships with Node.
> > >>>>>>>>
> > >>>>>>>> On Fri, May 10, 2019, 00:33 Jesse <purplecabb...@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.blot...@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-unsubscr...@cordova.apache.org
> > >>>>>>> For additional commands, e-mail: dev-h...@cordova.apache.org
> > >>>>>>>
> > >>>>>>
> > >>>>>> ------------------------------------------------------------
> > ---------
> > >>>>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > >>>>>> For additional commands, e-mail: dev-h...@cordova.apache.org
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>>
> > >>> ---------------------------------------------------------------------
> > >>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > >>> For additional commands, e-mail: dev-h...@cordova.apache.org
> > >>>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > >> For additional commands, e-mail: dev-h...@cordova.apache.org
> > >>
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >
> >
> >
>
> --
> Regards,
> Gandhi
>
> "The best way to find urself is to lose urself in the service of others
> !!!"
>

Reply via email to