This is essentially what I was referring to with my comment below. If you can improve the installation experience such that I don't have to care that you developed with node.js, so much the better. If I were a node.js developer I surely wouldn't want my global package name space polluted like that.
the solution is not write CLIs in JavaScript, unless you have a JS-library that you also want to make available as a CLI
packaging Node in a binary won't solve the problem of JavaScript's plagued ecosystem and in fact i'd rather prefer to be able to mitigate the issues/update packages myself rather than waiting for a new binary to release
I agree with your conclusion to not write cli tools in Javascript.
However, packaging node in a binary is pretty much what electron does today, albeit with a GUI.
Regardless, it's not a problem I wish to spend any effort to solve since it's not my problem and I've (we've) already dismissed the premise (writing CLI tools in js) lol.
Comments
This is essentially what I was referring to with my comment below. If you can improve the installation experience such that I don't have to care that you developed with node.js, so much the better. If I were a node.js developer I surely wouldn't want my global package name space polluted like that.
npm is not for end users.
the solution is not write CLIs in JavaScript, unless you have a JS-library that you also want to make available as a CLI
packaging Node in a binary won't solve the problem of JavaScript's plagued ecosystem and in fact i'd rather prefer to be able to mitigate the issues/update packages myself rather than waiting for a new binary to release
I agree with your conclusion to not write cli tools in Javascript.
However, packaging node in a binary is pretty much what electron does today, albeit with a GUI.
Regardless, it's not a problem I wish to spend any effort to solve since it's not my problem and I've (we've) already dismissed the premise (writing CLI tools in js) lol.
Another option is using Deno!