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
> 

Reply via email to