code for #2

[hemanth]

@zeke Code works fine.

For test if you want to stick we tape we would blue-tap or else we can use ava or something similar or may be just asserts ;)

[zeke]

This is cool, but it overrides the default behavior of simply instantiating a nice package. If we are to support this new functionality, I would like it to work without changing the existing API.

One way to do this would be to check the type of the argument passed to new Package(). If it's an object, treat it as a document from the registry. If it's a string, treat it as a package name to be downloaded.

[hemanth]

If it's a string, treat it as a package name to be downloaded.

@zeke But the constructor can't have any async stuff in it, right?

I also tried: class Package extends Promise ...

[crookedneighbor]

A nice thing about the existing api is that you can pass in private registry information too.

[crookedneighbor]

Another thing to be aware of, including got as part of the package itself increases the file size quite a bit, and doesn't play nice with browserifying because many browserify shims have to be included to make got work in a browser context.

[zeke]

Good points, @crookedneighbor. Maybe a better approach would be to create a new npm package called get-a-nice-package or something. We could link to it in the README here.

[hemanth]

@crookedneighbor I was thinking of the same, why not we use http instead?

@zeke I am up for fetch-nice-package I can use isomorphic-fetch what say?
But I still feel, we could use isomorphic-fetch here and enhance the PR? 🤔

[zeke]

fetch-nice-package and isomorphic-fetch sounds good to me. I like that idea better than trying to add more behavior and dependencies to this nice-package.