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
