Skip to content
This repository has been archived by the owner on Jan 5, 2024. It is now read-only.

Feature: Automatic Install #687

Open
fny opened this issue Sep 11, 2016 · 7 comments
Open

Feature: Automatic Install #687

fny opened this issue Sep 11, 2016 · 7 comments

Comments

@fny
Copy link

fny commented Sep 11, 2016

It would be lovely to have a flag that would just take care of any installation issues (e.g. typings install --do-whatever-you-need-to-do-to-install some-module.) I know this might seem pretty minor, but this back-and-forth has become tiresome:

typings install some-module

typings ERR! message Unable to find "some-module" ("npm") in the registry.
typings ERR! message However, we found "some-module" for 1 other source: "dt"

typings install dt~some-module

typings ERR! message Attempted to compile "some-module" as an external module, but it looks like a global module. You'll need to enable the global option to continue.

typings install dt~some-module --global

Finally! 
@blakeembrey
Copy link
Member

See existing issues about this. It used to be automatic once. But that just brings up a different set of issues with people asking why global doesn't automatically install when using sub-dependencies. The locations are all pretty straightforward though and documented in the README. Only dt is odd, but it's global 99% of the time anyway.

@blakeembrey
Copy link
Member

Also, I don't think it will never do the first thing you want. There's a huge difference between a definition that's global vs local. It's possible the global version isn't even for the same thing, just because a name matches it doesn't mean it's the same.

@blakeembrey
Copy link
Member

A good example is probably stripe in NPM vs stripe in global. One is for a browser, usually the stripe.js checkout code. One is for node. They are two completely different APIs. What do you think should be done?

@fny
Copy link
Author

fny commented Sep 12, 2016

Very good points, here are my thoughts:

  • This would be implemented with a flag, so it would be an opt-in feature (e.g. --lazy)
  • "I don't think it will never do the first thing you want." In practice, this would have always done the first thing I've wanted. We can warn the user when conflicting local/global packages
  • Stripe is a very good example! typings install --lazy stripe should run typings install dt~stripe --global instead of me having to manually test typings install stripe and typings install dt~stripe to figure out the final command needs to be typings install dt~stripe --global
  • My vote would be to install a package from the next most popular repository (e.g. npm > dt > global) adding the global flag on any given failure

@blakeembrey
Copy link
Member

@fny I don't think you understand. This is all how it worked when I first released it, before I even announced it. It turned out to be not great for various reasons.

Also, why would you expect it to install dt~stripe? This is exactly the issue, introducing things others dislike. I would prefer global > dt. I personally don't use any definitions from dt because I find them unmaintained more often than not. In fact, pre-1.0 had an option for defaultGlobalSource which was set to dt. I dropped that, because a few people disliked that it was the default (E.g. people using env is more common).

@blakeembrey
Copy link
Member

Sorry, that wasn't meant to be harsh. Multitasking can be bad. Popular is just subjective. The best one isn't possible to automatically know. Would it be useful to re-add a defaultGlobalSource? You can always try install [email protected] or earlier to get an idea of how some of this used to work. It's mostly compatible. It used to search by name, prompt, etc.

@martinjezek
Copy link

Hi @blakeembrey where do you get definitions from then? Do you write and maintain your own set of typings?

I personally don't use any definitions from dt because I find them unmaintained more often than not.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants