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 <purplecabb...@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 <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 >> !!!" >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
