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
