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 !!!"
