-
Notifications
You must be signed in to change notification settings - Fork 508
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
[Request] Automatically install default packages #139
Comments
As I don't use global packages, I don't have this kind of problems. I think that using global packages that are linked to the current Node version is mostly a user configuration smell. It is exactly like global variables. Most packages should be installed as a devDependency or a direct dependency to the project you're working on. It's easier to manage, and if you need an escape hatch, we have tools like Anyway, thanks for opening the issue. It keeps showing me that my way of using the computing machine is not the only way to do so, and things need to get better. However, I don't think we should allow bad practices.
This is an interesting idea but would make installation much, much slower. Also, it will produce inconsistencies and I'm not sure this will be used eventually, because you can have multiple versions (node 6 will have This comment suggests a different solution: having a new binary that will work like I'd be happy to develop that, but I don't have the time right now. I think this is a wonderful idea for an open-source, and if someone needs any help (by providing help with Reason or providing an API for fnm), I'd be glad to assist.
I also had the same thought. This is an interesting idea but opens up security holes. What if something calls I think you can manage by having an executable file called #!/bin/bash
$FNM=/usr/bin/local/fnm
/usr/bin/local/fnm $*
FNM_STATUS_CODE=$?
if [ "$1" == "install" && "$FNM_STATUS_CODE" == "0" ]; then
do_my_thing
fi instead of having hooks, you can compose your solution with simple scripting. |
😕 None of the packages I mentioned (and none of the other packages I have in I suppose if they were available via a package manager, I'd install most of them that way, but that's unlikely to happen in most cases just as e.g. most commands available as gems or CPAN modules (including my own) aren't packaged. Either way, I'd love to be able to discuss (or close) this without it turning into a sermon about how evil it is to use node the same way I use bash, perl, python, ruby, and every other interpreter on my system :-) (Also, it sounds like you do use global packages, just in a different (shared) directory, with all the risks of breakage/incompatibility that entails).
Yes, that's pretty much what I'm doing, e.g.: upgrade-node() {
fnm install latest && xargs -a ~/.fnm/default-packages npm install -g
} I can live with this. Just thought it might be worth considering at least facilitating a way to do this directly as it's a common requirement and there might be other uses for this kind of hook/plugin support. |
Hey! I just talked to @ronami about the same thing, and I first want to say I'm sorry. Didn't want to say that it's evil or something :) just that I wouldn't use global packages, however, I use a shared directory for like, 4 packages or something, that I'd really rather have installed using Homebrew, apt, etc, probably packaged with Zeit's pkg so if it works best with Node 6, it'll always run with Node 6, and don't force my computer to have a different Node installed.
You're right. I'm sorry for my last comment, which looks very poisonous when I reread it now. I think that the best option for general-purpose command-line utilities that aren't distributed using the system's package manager is to have something like I suggested. A small wrapper around fnm and npm/yarn, if you'd like.
Yeah, I agree but I think we should fix the underlying issue - supporting global packages, let's do this. Even if we'll add hooks, I think that simple users won't understand how to use them, and it'll be used by just a few. I think we can create a simple binary that fixes this huge issue. But maybe it won't be as simple as I think 😜 What do you think? I hope I'll have time to sketch a simple POC in the next week or so |
No worries :-) Thanks for discussing it 👍
Yes, agreed. I'm hoping QuickJS (which can compile to native code) will become an option for this as well once a Node.js compatibility shim emerges.
Sounds great, thanks! |
woooo QuickJS looks awesome! |
@Schniz, as I understood this feature request, it's about migrating global packages when upgrading from one Node.js version to another.
explained here: |
yeah, it makes sense. I will happily accept a PR that adds |
You’d know because it’d be the one that ships with node. |
I started playing around with a solution for consistent global package installations — https://github.com/Schniz/gpkg It'll always use the same Node version, no matter what version you currently use. So, if a binary needs Node 13, you can still use it if you're currently |
@Schniz any progress on this? |
Hmmm sure but regarding what? Adding |
I’ll explain more to support async communication 😄 i haven’t implemented that yet. I’d be happy to receive a PR, if that’s what you’re after. 😸 |
Is there anyone working on "—reinstall-packages-from" feature? |
I have been trying to add There may be a better way that I don't know. |
I have sent a PR: #510 |
(There are some similar-sounding issues, but they're talking about sharing global packages across different versions rather than installing them per-version.)
It'd be nice to be able to automatically (re-)install a list of global packages when a new version is installed as can be done via the default-packages file in nvm:
e.g.:
$ cat $NVM_DIR/default-packages
Or, failing that, some kind of post-install hook?
The text was updated successfully, but these errors were encountered: