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
