hyper: Cannot Install Plugins/Themes with CLI

We’re using a rebuilt version of yarn to install plugins.

I don’t think there’s enough demand for such a setting that it would be worth adding and maintaining.

There is a workaround:

1. Add plugin to ~/.hyper.js
2. Open terminal and cd ~/.hyper_plugins/
3. Install via your low security npm npm install
4. Plugins should work

Hope that helps 👍

Also sounds like your school is intercepting your traffic via a custom SSL cert, I would try everything to get around that, they are decrypting your traffic and can get all your passwords and everything you send on the webs…

Sure disabling is not a good idea. Introducing the functionality to add a custom CA would be the preferred way. However, how does a VPN solves the problem? I assume most people using hyper are devs or other IT guys working in a Company with a certain policy which are most likely neither allowed to build a vpn outside the company network, nor wiling to do such an affort for a “plugin”

While I disagree with the tone of @dannyyy’s comment, I understand the point they are trying to make.

@albinekb I agree that strict-ssl=false is a security risk. At the same time, advocating that users try to bypass their school/corporate firewall is a non-starter for most. There should be a way (preferences setting?) to set a cafile path that the yarn-standalone will use as a trusted ca so that users can CHOOSE to trust their corporate proxy ca. That way you can still maintain SSL, install plugins, and not lose your job/get expelled. This approach works very well (it’s how I use npm at work currently).

sadly not much we can do here, we also have a ton of other issues about the CLI so closing this one

I just realized that you can use the localPlugins config to get around this problem:

  // in development, you can create a directory under
  // `~/.hyper_plugins/local/` and include it here
  // to load it and avoid it being `npm install`ed
  localPlugins: [
    'hyper-material-theme',
    'hyper-tabs-enhanced'
  ],

Just clone the plugins to ~/.hyper_plugins/local/ and run npm install inside of each plugin. This is the best workaround I’ve found so far and it isn’t that much of an inconvenience for me. Might still be nice to have a more built-in config setup, but not a big deal with this workaround.

If I’m behind an institutional firewall that is reading my passwords and I’ve already installed the trusted CA, hyper is not going to protect me by refusing to install plugins. I’d have given up control of security well before getting to this point. I’m not sure what real harm this is trying to protect me from.

I share the same problem than the others have. I’m behind a corporate web-proxy. Well SSL interception is also in place but the corporate root CAs where in the certificate store.

I have npm installed and set the necessary http_proxy/https_proxy/no_proxy config entries. As well as added the same entries to the environment variables and my windows default proxy settings are also set. npm, git and many others are performing very well with this settings. Only hyper is fully ignoring all kind of proxy settings. @albinekb respecting system proxy settings isn’t a security flaw, requesting to download and place suspicous things in the ~/.hyper_plugins/.

After reading this and other issues I believe hyper is not targeting serious IT professionals. I guess they promote a fancy terminal app to scriptkiddis. I see no other reason for that kind of ignorance over month/years. In addition I have to assume, that their cloud products also targets hobbyist an not serious professional customers.

For all the others cmder on Windows is a great terminal alternative.

Curious if any progress has been made on this. It seems that Hyper doesn’t honor the NODE_EXTRA_CA_CERTS environment variable if it’s set. We use a proxy at work and I had to set that environment variable with the path to the cert used by the proxy. Then npm will trust that cert and allow downloads. I can npm install plugins in the plugin directory, but Hyper can’t update/install plugins itself.

Why wouldn’t you just honor strict-ssl=false in the .npmrc?