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
