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 <purplecabb...@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 <dmitry.blot...@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 <dmitry.blot...@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 <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 >> >>
